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INTRODUCTION  TO  VOLUME  4 


In  ihc  early  days  of  the  Internet,  the  management  of  naincs  for  hosts  and  other  resources  was  carried  out  using  a 
master  host  table,  called  the  Internet  Host  Table,  maintained  by  the  Network  Information  Center  (NIC)  at  SRI 
International.  All  sites  in  the  Internet  periodically  received  updated  copies  of  this  Uible.  As  the  Internet  grew  in  size, 
this  centralized  approach  became  unacceptable.  To  solve  this  problem,  the  domain  name  system  (DNS)  was 
introduced  in  the  Internet.  The  DNS  consi.sts  of  the  synta.x  to  specify  the  names  of  entities  in  the  Internet  in  a 
hierarchical  manner,  the  rules  used  for  delegating  authority  over  names,  and  the  system  implementation  that  actually 
maps  names  to  Internet  addresses. 

Volume  Four  of  the  Internet  Protocol  Handbook  constitutes  the  most  comprehensive  source  of  information  on  the 
DNS  to  date.  This  volume  is  organized  in  two  parts.  Section  1  contains  articles  and  Requests  for  Comments  (RFCs) 
that  intrcKluce  the  main  philosophy,  concepts,  and  facilities  of  the  DNS;  describe  in  detail  the  DNS  protocol 
standards  and  implementation;  discuss  the  requirements  that  an  Internet  domain  server  must  meet  and  the  current 
organization  of  domains  in  the  Internet;  provide  guidelines  for  establishing  domains  and  for  operating  a  domain 
name  server,  detail  the  changes  to  the  Internet  mail  system  related  to  domains;  and  describe  how  to  obtain  additional 
information  about  the  DNS  through  electronic  mail  and  points  of  contact  in  the  Internet.  Section  2  of  this  volume 
contains  background  reading  that  is  useful  in  understanding  the  transition  from  the  Internet  Host  Table  to  the  DNS 
A  glossary  of  DNS  acronyms  is  provided  at  the  end  of  this  volume. 

Each  section  of  this  volume  provides  a  brief  description  of  its  overall  contents  and  a  summary  of  each  of  the  articles 
and  RFCs  it  includes.  All  of  the  reprints  that  appear  in  this  volume  bear  their  original  page  numbering;  we  have 
included  the  page  numbering  for  the  Handbook  below  the  footer  line. 
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1.  THE  DOMAIN  NAME  SYSTEM 


Section  1  contains  articles  and  RFCs  that  describe  the  design,  standards,  and  implementation  of  the  DNS;  the 
administration  and  operation  of  domains;  and  how  to  obtain  more  information  about  the  DNS. 

The  first  article,  by  Paul  Mockapctris,  one  of  the  main  de.signers  of  the  DNS,  provides  a  brief  authoritative 
introduction  to  the  design  philosophy  of  the  DNS. 

RFC  1034  introduces  the  domain-style  names,  how  such  names  are  used  for  Internet  mail  and  host  address  support, 
and  the  protocols  and  servers  used  to  implement  domain  niune  facilities.  After  providing  an  introduction  to  the 
history  of  the  DNS  and  iLs  design  goals,  it  de;  cribes  DNS  elements,  usage  assumptions,  and  facets  of  the  domain 
name  space  specifications  and  Resource  Records  (RRs).  Deuiils  are  provided  regarding  the  functions  of  name 
servers  and  resolvers.  .An  e.xample  scenario  guides  tlie  reader  through  several  sample  queries  and  re.si)onses.  This 
RFC  is  updated  by  RFC  1 101,  which  is  included  in  this  volume,  and  obsoletes  RFC  973,  RFC  8S2,  and  RFC  SS3. 

RFC  1035  provides  details  of  the  DNS  and  proux'ol.  It  first  introduces  the  DNS  and  discus.scs  common  ss  stem 
configurations  and  conventions.  It  then  covers  the  domain  name  space  and  Re.source  Record  (RR)  definitions, 
including  a  list  of  standard  RRs.  The  RFC  describes  the  format  for  communication  wiiliin  the  domain  protocol,  the 
master  files  u.scrl  to  define  /ones,  and  implementations  for  a  name  serv'cr  and  resolver.  RFC  1035  ai.so  includes 
some  thoughts  on  mail  support.  This  RFC  is  updated  by  RFC  1 101,  which  is  included  in  this  volume,  and  obsoletes 
RFC  973,  RFC  882,  and  RFC  883. 

RFC  1101  presents  two  extensions  to  the  current  DNS.  The  first  extension  is  a  proposed  restructuring  of  network 
names,  addresses,  and  subnets  to  be  compatible  with  expanded  host  name  support  systems.  The  second  is  a  general 
sugge.stion  that  would  allow  mapping  between  given  network  numbers  and  network  names.  The  role  of  the  DD.N 
NIC  in  allocating  network  names  and  numbers  is  brielly  di.scus.sed.  This  RFC  updates  RFC  10.34  and  RFC  1035. 

RFC  920  de.scribes  the  requirements  for  establishing  a  new  domain  in  the  Internet.  In  addition,  this  RFC  reviews  the 
purpose  of  domains,  gives  examples  of  domains,  introduces  tlie  set  of  top-level  domains,  and  advises  hosts  on  how¬ 
to  choose  a  domain. 

RFC  1032  explains  the  roles  and  responsibilities  of  the  Domain  Administrator  (DA)  and  the  domain  technical  and 
/one  contact,  and  discu.sses  the  different  domain  levels,  the  domain  names,  and  DDN  NIC  policies  .egarding 
chixising  both.  This  RFC  aLso  presents  the  exact  procedures  for  registering  a  domain  with  the  DDN  NIC  and 
provides  a  sample  domain  registration  form  and  references  to  further  information. 

RFC  1033  provides  specific  guidelines  for  domain  administrators,  explaining  how  to  operate  a  domain  serv-erand 
how  to  maintain  their  part  of  the  hierarchical  domain  database.  This  RFC  explains  what  a  domain  server  needs  to  get 
started,  how  it  figures  out  the  zones  it  should  pay  attenuon  to,  and  how  it  finds  the  root  servers.  It  discusses  RRs  and 
explains  the  fields  within  RRs.  It  provides  instructions  for  adding  or  deleting  subdomains,  hosts,  and  gateways,  as 
well  as  for  handling  complaints.  It  also  includes  example  domain-server  database  files. 
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R(  ('  9'’4  doscritvs  hovA.  mailers  route  messages  that  arc  addressed  to  a  domain  name.  This  RFC  first  describes  what 
domain  servers  knovs  and  general  routing  guidelines,  then  explains  how  mailers  determine  where  to  .send  a  me.s.sage. 
This  determination  is  made  by  issuing  a  query  lor  the  Mail  Lxehange  (MX)  RRs  lor  a  deslinalion  host,  and  by 
iraerpretmg  me  list  ot  M.X  RRs  reecived.  1  his  process  is  diseu.s.scd  and  examples  of  message  routing  arc  given. 

1  lie  last  par'  ot  Section  1 .  by  Jose  C iareia-Luna  and  Mary  SLihl,  describes  a  number  of  dil ferent  ways  to  obtain 
additional  information  about  the  DNS,  ineUidmg  DNS  implememalions. 
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Domains 


by  Paul  Mockapelris 


1.1.  Domains 

Domains 

History 

In  any  large  internet,  the  task  of  organ  jig  and  managing  names  for  users,  host.-  and  other  objects  be¬ 
comes  increasingly  im-  rtant  as  the  internet  gfow-s  in  size.  The  DARPA  Internet  started  out  with  a  system 
inherited  from  the  ARPANET,  in  which  the  SRI  Network  Information  Center  (NIC)  maintained  a  file 
called  HOSTS.TXT  Listing  aU  of  the  hosts,  networks,  and  gateways,  together  with  the  corresponding  ad¬ 
dresses.  The  file  was  maintained  by  the  NIC  staff  and  distributed  to  all  hosts  via  direct  and  indirect  file 
transfer.  As  workstations  and  local  networks  came  to  dominate  the  internet  population,  the  size,  central¬ 
ized  maintenance  and  universal  distribution  of  HOSTS.TXT  became  impractical.  To  solve  this  problem,  a 
distributed  service  called  the  Domain  Name  System  (DNS)  was  defined  in  1983,  and  has  been  miOdtied 
and  extended  since  then. 

The  HOSTS  TXT  file  is  still  maintained,  but  contains  an  ever-decreasing  subset  of  the  mfonnation  avail¬ 
able  from  the  DNS.  HOSTS  TXT  currently  has  on  the  order  of  6,000  entries  while  the  DNS  has  over 

100,000. 

What  is  the  basic  scheme? 

The  basic  idea  behind  the  DNS  is  that  name  cre?*ion,  control,  and  maintenance  must  be  distributed, 
along  Mith  the  ability  to  associate  information  with  the  names.  The  names  created  in  this  system  are  called 
domain  names,  and  the  information  associated  with  them  is  called  resource  records  (RRs). 

To  get  the  distribuuon  of  control  while  keeping  adminisuators  off  of  each  other’s  toes,  domain  names  use 
a  hierarchical  or  tree  structure.  It’s  not  too  far  off  to  think  of  this  as  creating  a  distributed  "org  chart"  for 
all  of  the  organizations,  hosts,  etc.  in  the  Internet.  The  idea  is  that  each  administrator  gets  authority  over 
a  section  of  the  total  tree  and  is  free  to  cut  or  add  at  and  below  that  point.  Of  course,  it’s  a  bit  more 
complicated  than  that,  since  an  administrator  can  create  and  delegate  control  for  a  subsection  of  his 
subtree,  and  so  on.  Technically  speaking,  a  domain  is  a  full  subtree  in  the  nam.e  space  (usually  delegated 
lO  a  particular  organization),  and  a  zone  is  a  domain  less  subdomains  which  have  been  delegated  away. 

In  the  DNS  tree  structure,  each  node  get«  a  label  that  must  distinguish  it  from  its  brothers.  The  absolute 
name  of  any  node  is  a  list  of  its  label  together  with  the  labels  of  aU  of  its  ancestors,  all  the  way  back  to  the 
root  of  the  tree.  When  we  type  these  unique  names,  we  separate  labels  with  dots.  A  sample  tree  might  be; 


(Note  that  this  is  a  quite  skimpy  example;  the  real  name  space  has  over  100,000  names,  and  typical 
names  have  4  or  five  levels.  The  root  of  the  tree  has  a  special,  reserved,  null  label.) 
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The  typical  user  doesn’t  see  a  graphical  tree  structure  but  instead  sees  names  derived  from  the  structure. 
In  this  tree,  the  bottom  node,  with  the  label  "Poneria"  has  an  absolute  name  of  "Poneria.ISl.EDU" . 
Note  that  since  the  requirement  for  uniqueness  is  only  between  brother  nodes,  we  could  create  another 
’’Poneria”  under  ARPA  or  any  other  node  which  does  not  already  have  one.  The  DNS  doesn’t  restrict 
the  use  of  mierior  nodes,  so  1SI.EDU  is  also  a  domain  name. 

Domain  names,  in  themselves,  don’t  define  hosts,  organizations,  or  any  other  object  (although  they  are 
most  often  used  for  hosts).  Instead,  they  provide  "places”  where  this  information  may  be  kept.  The 
informauon  takes  the  form  of  a  set  of  RRs;  the  set  of  RRs  associated  with  a  name  may  be  empty,  in  which 
case  the  name  is  merely  a  placeholder  or  it  may  hold  the  Internet  address,  mail  exchange,  or  a  variety  of 
other  types  of  data.  Thus  you  can  tell  that  a  name  denotes  a  host  by  seeing  if  it  has  host  information 
stored  in  it,  rather  than  asking  its  type.  In  the  case  of  a  host,  the  name  will  have  one  address  RR  for  each 
IP  address  the  host  has,  and  might  also  have  a  HINFO  RR  describing  the  host  OS  and  CPU. 

How  does  this  affect  the  average  user? 

Side  effects  of  distribution 

The  major  effect  that  the  average  user  sees  is  a  lot  of  names  with  dots  in  them.  Sometimes  this  is  useful, 
since  the  parent  domains  will  usually  describe  a  geographical  location  or  type  of  organization,  although  it 
sometimes  means  more  typing  Users  should  be  aware  that  just  because  a  name  has  dots  in  it,  and  may 
even  have  hierarchical  components,  doesn’t  mean  that  the  name  is  registered  with  the  DNS.  For  exam¬ 
ple,  ’’.UUCP"  is  a  frequent  top-level  pseudo-domain,  although  it  is  not  registered  in  the  DNS. 

The  distribuuon  of  the  database  means  that  you  can  usually  add  hosu,  change  the  name  of  your  host, 
reconfigure  IP  addresses,  or  other  database  updates  as  a  purely  local  matter  (once  you  get  control  of  a 
domain).  All  you  need  to  do  is  get  your  local  administrator  to  make  the  changes. 

The  price  paid  for  the  distributed  control  is  that  you  will  occasionally  have  to  wait  while  information  is 
retrieved  from  a  distant  source.  The  DNS  eliminates  much,  but  not  all  of  this  delay  through  a  comprehen¬ 
sive  caching  strategy  In  cases  where  the  Internet  is  partitioned  by  routing  problems  or  the  like,  it  may  be 
impossible  to  get  information  about  a  name  until  connectivity  is  restored. 

Names  aren't  just  for  hosts  anymore 

VtTiile  the  DNS  was  created  to  replace  HOSTS.TXT,  it  has  also  been  used  to  store  new  types  of  informa¬ 
tion.  The  prime  example  is  a  new  class  of  information  called  Mail  Exchange  or  MX  information.  MX 
allows  an  organization  to  channel  mail  for  all  of  its  users  to  mail  service  machines,  rather  than  individual 
user's  workstations.  In  addition  to  providing  redundant  backups  to  speed  mail  delivery,  it  also  allows 
organizations  to  have  domain  names  witliout  being  directly  connected  to  the  DARPA  Internet;  they  just 
use  MX  to  direct  their  mail  to  the  appropriate  mail  gateway. 

What  are  the  active  components? 

DNS  services  are  provided  by  two  new  pieces  of  software:  name  servers  and  resolvers. 

Name  servers  are  repositories  of  information.  They  are  usually  independent  server  processes.  Name 
servers  load  the  information  prepared  by  the  local  administrators  and  make  it  available  via  UDP  queries. 
Name  servers  also  have  a  zone  transfer  protocol  that  allows  multiple  name  servers  to  automatically  acquire 
redundant  copies  of  rone  data.  This  means  that  even  if  one  of  the  name  servers  for  a  particular  domain 
crashes,  the  other  redundant  ones  will  still  answer  queries  for  the  domain. 
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Resolvers  are  programs  which  tak»  '“quests  arid  seek  out  the  proper  name  server  to  answer  the 
request.  Resolvers  may  be  autonomous  processes  or  may  be  code  linked  into  user  programs.  Since  name 
servers  typically  only  know  about  a  small  pan  of  the  whole  name  spac“,  and  since  server  crashes  and 
network  problems  make  retries  and  use  of  alternate  name  servers  necessary,  this  important  role  insulates 
the  user  from  the  realities  of  the  Internet. 

This  division  is  often  logical,  rather  than  actual  The  DNS  allows  for  most  of  the  resolver  functions  to  be 
included  tn  spiecial  local  name  servers.  This  technique  is  used  in  BIND,  the  BSD  name  server. 

How  have  domains  been  organized? 


The  DNS  is  a  technical  method  for  describing  a  large  hierarchy  in  a  distributed  manner.  As  you  might 
imagine,  the  reservauon  of  familiar  names,  and  issues  related  to  who  controls  what  generate  a  lot  of 
discussion.  The  important  point  here  is  that  technically,  almost  any  organization  is  possible,  and  differert 
styles  may  prevail  in  different  parts  of  the  name  space. 


The  top  levels  of  the  name  space  were  organized  some  time  ago  in  RFC  920,  An  excerpt  (there  are  over 
30  domains  under  the  root,  and  over  1000  delegated  zones  overall)  of  the  top-level  organization  ts  shown 
below: 


Three  types  of  names  appear  immediately  below  the  r  ..  The  first  type  is  the  so-called  "generic"  do¬ 
mains  such  as  EDU  (Educational),  COM  (Commercial;.  These  were  defmed  in  RFC  920,  and  are  meant 
to  divide  by  organization  type.  The  main  ones  are  shown  below: 


Domain 

Purpose 

Examples 

MIL 

US  Military 

ARMY.MIL.  NAVY.MIL 

GOV 

Other  US  government 

NASA.GOV 

EDU 

Educational 

ISI.EDU.  MIT.EDU 

COM 

Commercial 

3M.COM,  SUN.COM 

NET 

NICs  and  NOCs 

Nyser.NET 

ORG 

Non-profit  organizations 

MITRE.ORG 

AD  of  these  are  at  present  administered  by  the  SRI-MC.  The  EDU  and  COM  domains  are  the  most 
popular,  with  several  hundred  subdomains  delegated  to  various  universities  and  companies  The  MIL 
domain  is  in  the  midst  of  a  reorganizat'on  mandated  by  DDN  42.  which  will  give  it  a  more  substructure 
Note  that  although  the  MIL  and  GOV  domains  are  restricted  to  US  use,  the  NIC  has  and  will  register 
non-US  names  in  COM,  EDU,  etc. 

The  second  type  of  top  level  domain  is  the  ARPA  domain.  This  was  used  to  bootstrap  old  HOSTS.TXT 


-  3  - 


INTERNET  PROTOCOL  HANDBOOK  -  Volume  Four 


1989 


names  into  the  DNS  world,  and  new  registrations  are  strongly  discouraged.  Indeed,  aU  MILNET  hosts  are 
being  reorgaruzed  into  the  MIL  domain. 

The  last  type  of  domain  is  allocated  by  country.  Every  country  has  its  ISO  3166  standard  2-letter  acro¬ 
nym  resen'ed  for  it,  whether  it  has  been  claimed  or  not.  The  policies  of  these  domains  are  as  varied  as 
the  countries  themselves. 

The  US  domain 

The  country  tof>-leveI  doma-;.  for  the  United  States  is  controlled  by  Jon  Postel  (Posiel^'ISl.EDU),  who 
sets  its  pobey  and  administered  by  Ann  Westine  (Westine@ISl  EDU).  At  present,  the  US  domain  is 
organized  geographically;  states  occur  directly  under  US.  cities  under  states,  and  individual  names  under 
cities.  Although  registration  in  the  US  domain  does  not  imply  auihorization  to  connect  to  the  D.ARPA 
Internet,  small  companies  and  individuals  can  register  in  the  US  domain,  so  long  as  they  are  not  registered 
elsewhere.  Since  the  US  domain  w'ill  accept  MX -only  entries,  registration  is  independent  of  direct  con¬ 
nection  to  the  Internet. 

At  present,  about  100  organizations  are  registered  in  the  US  domain.  An  example  name  is 
"femwood.mpk.ca.us",  which  is  the  "femwood"  host  in  Menlo  Park,  CaUfomia.  States  and  cities  may  be 
delegated  to  local  administrators  in  the  future. 

How  do  I  find  out  more? 

The  philosophy  and  inner  workings  of  the  DNS  are  described  in  RFCs  1034  and  1035.  RFC  920  de¬ 
scribes  the  rationale  for  the  design  of  the  top  levels  of  the  name  space.  The  NAMEDROPPERS@SRl- 
MC.ARPA  mailing  list  discusses  general  DNS  issues,  while  questions  more  specific  to  BIND  are  discussed 
in  BI.N'Dtg UCBARPA.Berkeley.EDU.  RFC  1101  describes  a  plan  to  extend  domain  names  for  network 
(and  subnetwork)  information,  along  with  some  discussion  about  possible  future  uses  of  the  D.NS  for  a 
variety  of  other  information. 
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1.2.  Domain  Names  -  Concepts  and  Facilities  [RFC1034] 

Network  Working  Group  P.  Mockapetris 

Request  for  Comments:  1034  ISI 

Obsoletes:  RFCs  882,  883,  973  November  1987 


DOMAIN  NAMES  -  CONCEPTS  AND  FACILITIES 


1.  STATUS  OF  THIS  MEMO 

This  RFC  is  an  introduction  to  the  Domain  Name  System  (DNS) ,  and  omits 
many  details  which  can  be  found  in  a  companion  RFC,  "Domain  Names  - 
Implementation  and  Specification"  [RFC-1035] .  That  RFC  assumes  that  the 
reader  is  familiar  with  the  concepts  discussed  in  this  memo. 

A  subset  of  DNS  functions  and  data  types  constitute  an  official 
protocol.  The  official  protocol  includes  standard  queries  and  their 
responses  and  most  of  the  Internet  class  data  formats  (e.g.,  host 
addresses) . 

However,  the  domain  system  is  intentionally  extensible.  Researchers  are 
continuously  proposing,  implementing  and  experimenting  with  new  data 
types,  query  types,  classes,  functions,  etc.  Thus  while  the  components 
of  the  official  protocol  are  expected  to  stay  essentially  unchanged  and 
operate  as  a  production  service,  experimental  behavior  should  always  be 
expected  in  extensions  beyond  the  official  protocol.  Experimental  or 
obsolete  features  are  clearly  marked  in  these  RFCs,  and  such  information 
should  be  used  with  caution. 

The  reader  is  especially  cautioned  not  to  depend  on  the  values  which 
appear  in  examples  to  be  current  or  complete,  since  their  purpose  is 
primarily  pedagogical.  Distribution  of  this  memo  is  unlimited. 

2.  INTRODUCTION 

This  RFC  introduces  domain  style  names,  tlieir  use  for  Internet  mail  and 
host  address  support,  and  the  protocols  and  servers  used  to  implement 
domain  name  facilities. 

2.1.  The  history  of  domain  names 

The  impetus  for  the  development  of  the  domain  system  was  growth  in  the 
Internet : 

-  Host  name  to  address  mappings  were  maintained  by  the  Network 
Information  Center  (NIC)  in  a  single  file  (HOSTS.TXT)  which 
was  FTPed  by  all  hosts  [RFC-952,  RFC-953] .  The  total  network 
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bandwidth  consumed  in  distributing  a  new  version  by  this 
scheme  is  proportional  to  the  square  of  the  number  of  hosts  in 
the  network,  and  even  when  multiple  levels  of  FTP  are  used, 
the  outgoing  FTP  load  on  the  NIC  host  is  considerable. 
Explosive  growth  in  the  number  of  hosts  didn't  bode  well  for 
the  future. 

-  The  network  population  was  also  changing  in  character.  The 
timeshared  hosts  that  made  up  the  original  ARPANET  were  being 
replaced  with  local  networks  of  workstations.  Local 
organizations  v ere  administering  their  own  names  and 
addresses,  but  had  to  wait  for  the  NIC  to  change  HOSTS.TXT  to 
m.ake  changes  visible  to  the  Internet  at  large.  Organizations 
also  wanted  some  local  structure  on  the  name  space. 

-  The  applications  on  the  Internet  were  getting  more 
sophisticated  and  creating  a  need  for  general  purpose  name 
service . 


The  result  was  several  ideas  about  name  spaces  and  their  management 
[IEN-116,  RFC-799,  RFC-819,  RFC-830].  The  proposals  varied,  but  a 
common  thread  was  the  idea  of  a  hierarchical  name  space,  with  the 
hierarchy  roughly  corresponding  to  organizational  structure,  and  names 
using  as  the  character  to  mark  the  boundary  between  hierarchy 

levels.  A  design  using  a  distributed  database  and  generalized  resources 
was  described  in  [RFC-882,  RFC-883] .  Based  on  experience  with  several 
implementations,  the  system  evolved  into  the  scheme  described  in  this 
memo . 

The  terms  "domain"  or  "domain  name"  are  used  in  many  contexts  beyond  the 
DNS  described  here.  Very  often,  the  term  domain  name  is  used  to  refer 
to  a  name  with  structure  indicated  by  dots,  but  no  relation  to  the  DNS. 
This  is  particularly  true  in  mail  addressing  [Quarterman  86] . 

2.2.  DNS  design  goals 

The  design  goals  of  the  DNS  influence  its  structure.  They  are: 

-  The  primary  goal  is  a  consistent  name  space  which  will  be  used 
for  referring  to  resources.  In  order  to  avoid  the  problems 
caused  by  ad  hoc  encodings,  names  should  not  be  required  to 
contain  network  identifiers,  addresses,  routes,  or  similar 
information  as  part  of  the  name. 

-  The  sheer  size  of  the  database  and  frequency  of  updates 
suggest  that  it  must  be  maintained  in  a  distributed  manner, 
with  local  caching  to  improve  performance.  Approaches  that 
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attempt  to  collect  a  consistent  copy  of  the  entire  database 
will  becomie  more  and  more  expensive  and  difficult,  and  hence 
should  be  avoided.  The  same  principle  holds  for  the  structure 
of  the  name  space,  and  in  particular  mechanisms  for  creating 
and  deleting  names;  these  should  also  be  distributed. 

-  Where  there  tradeoffs  between  the  cost  of  acquiring  data,  the 
speed  of  updates,  and  the  accuracy  of  caches,  the  source  of 
the  data  should  control  the  tradeoff. 

-  The  costs  of  implementing  such  a  facility  dictate  that  it  be 
generally  useful,  and  not  restricted  to  a  single  application. 

We  should  be  able  to  use  names  to  retrieve  host  addresses, 
mailbox  data,  and  other  as  yet  undetermined  information.  All 
data  associated  with  a  name  is  tagged  with  a  type,  and  queries 
can  be  limited  to  a  single  type. 

-  Because  we  want  the  name  space  to  be  useful  in  dissimilar 
networks  and  applications,  we  provide  the  ability  to  use  the 
same  name  space  with  different  protocol  families  or 
management.  For  example,  host  address  formats  differ  between 
protocols,  though  all  protocols  have  the  notion  of  address. 

The  DNS  tags  all  data  with  a  class  as  well  as  the  type,  so 
that  we  can  allow  parallel  use  of  different  formats  for  data 
of  type  address. 

-  We  want  name  server  transactions  to  be  independent  of  the 
communications  system  that  carries  them.  Some  systems  may 
wish  to  use  datagrams  for  queries  and  responses,  and  only 
establish  virtual  circuits  for  transactions  that  need  the 
reliability  (e.g.,  database  updates,  long  transactions);  other 
systems  will  use  virtual  circuits  exclusively. 

-  The  system  should  be  useful  across  a  wide  spectrum  of  host 
capabilities.  Both  personal  computers  and  large  timeshared 
hosts  should  be  able  to  use  the  system,  though  perhaps  in 
different  ways. 

2.3.  Assumptions  about  usage 

The  organization  of  the  domain  system  derives  from  some  assumptions 
about  the  needs  and  usage  patterns  of  its  user  community  and  is  designed 
to  avoid  many  of  the  the  complicated  problems  found  in  general  purpose 
database  systems . 

The  assumptions  are; 

-  The  size  of  the  cotal  database  will  initially  be  proportional 
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to  the  number  of  hosts  using  the  system,  but  will  eventually 
grow  to  be  proportional  to  the  number  of  users  on  those  hosts 
as  mailboxes  and  other  information  are  added  to  the  domain 
system. 

-  Most  of  the  data  in  the  system  will  change  very  slowly  (e.g.,  j 

mailbox  bindings,  host  addresses) ,  but  that  the  system  should 

be  able  to  deal  with  subsets  that  change  more  rapidly  (on  the  | 

order  of  seconds  or  minutes) .  i 

-  The  administrative  boundaries  used  to  distribute 

responsibility  for  the  database  will  usually  correspond  to  j 

organizations  that  have  one  or  more  hosts.  Each  organization 

that  has  responsibility  for  a  particular  set  of  domains  will  | 

provide  redundant  name  servers,  either  on  the  organization's 
own  hosts  or  other  hosts  that  the  organization  arranges  to 
use . 

-  Clients  of  the  domain  system  should  be  able  to  identify 
trusted  name  servers  they  prefer  to  use  before  accepting 
referrals  to  name  servers  outside  of  this  "trusted"  set. 

-  Access  to  information  is  more  critical  than  instantaneous 
updates  or  guarantees  of  consistency.  Hence  the  update 

process  allows  updates  to  percolate  out  through  the  users  of  i 

the  domain  system  rather  than  guaranteeing  that  all  copies  are 

simultaneously  updated.  When  updates  are  unavailable  due  to 

networ)c  or  host  failure,  the  usual  course  is  to  believe  old 

information  while  continuing  efforts  to  update  it.  The 

general  model  is  that  copies  are  distributed  with  timeouts  ror 

refreshing.  The  distributor  sets  the  timeout  value  and  the 

recipient  of  the  distribution  ic  responsible  for  performing 

the  refresh.  In  special  situations,  very  short  intervals  can 

be  specified,  or  the  owner  can  prohibit  copies. 

-  In  any  system  that  has  a  distributed  database,  a  particular 
name  server  may  be  presented  with  a  query  that  can  only  be 
answered  by  some  other  server.  The  two  general  approaches  to 
dealing  with  this  problem  are  "recursive",  in  which  the  first 
server  pursues  the  query  for  the  client  at  another  server,  and 
"iterative",  in  which  the  server  refers  the  client  to  another 
server  and  lets  the  client  pursue  the  query.  Both  approaches 
have  advantages  and  disadvantages,  but  the  iterative  approach 
is  preferred  for  the  datagram  style  of  access.  The  domain 
system  requires  implementation  of  the  iterative  approach,  but 
allows  the  recursive  approach  as  an  option. 
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The  domain  system  assumes  that  all  data  originates  in  master  files 
scattered  through  the  hosts  that  use  the  domain  system.  These  master 
files  are  updated  by  local  system  administrators.  Master  files  are  text 
files  that  are  read  by  a  local  name  server,  and  hence  become  available 
through  the  name  servers  to  users  of  the  domain  system.  The  user 
programs  access  name  servers  through  standard  programs  called  resolvers. 

The  standard  format  of  master  files  allows  them  to  be  exchanged  between 
hosts  (via  FTP,  mail,  or  some  other  mechanism);  this  facility  is  useful 
when  an  organization  wants  a  domain,  but  doesn't  want  to  support  a  name 
server.  The  organization  can  maintain  the  master  files  locally  using  a 
text  editor,  transfer  them  to  a  foreign  host  which  runs  a  name  server, 
and  then  arrange  with  the  system  administrator  of  the  name  server  to  get 
the  files  loaded. 

Each  Post's  namie  servers  and  resolvers  are  configured  by  a  local  system 
adm.inist  rator  [RFC-1033]  .  For  a  name  server,  this  configuration  data 
includes  the  identity  of  local  master  files  and  instructions  on  which 
non-local  master  files  are  to  be  loaded  from  foreign  servers.  The  name 
server  uses  the  master  files  or  copies  to  load  its  zones.  For 
resolvers,  the  configuration  data  identifies  the  name  servers  which 
should  be  the  primary  sources  of  information. 

The  domain  system  defines  procedures  for  accessing  the  data  and  for 
referrals  to  other  name  servers.  The  domain  system  also  defines 
procedures  for  caching  retrieved  data  and  for  periodic  refreshing  of 
data  deiined  by  the  system  administrator. 

The  system  administrators  provide; 

-  The  definition  of  zone  boundaries. 

-  Master  files  of  data. 

-  Updates  to  master  files. 

-  Statements  of  the  refresh  policies  desired. 

The  domain  system  provides: 

-  Standard  formats  for  resource  data. 

-  Standard  methods  for  querying  the  database. 

-  Standard  methods  for  name  servers  to  refresh  local  data  from 
foreign  name  servers. 
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2.4.  Elements  of  the  DNS 

The  CN3  has  three  major  components: 

-  The  DOMAIN  NAME  SPACE  and  RESOURCE  RECORDS,  v;hich  are 
specifications  for  a  tree  structured  name  space  and  data 
associated  with  the  names.  Conceptually,  each  node  and  leaf 
of  the  domain  name  space  tree  names  a  set  of  information,  and 
query  operations  are  attempts  to  extract  specific  types  of 
information  from  a  particular  set.  A  query  names  the  domain 
name  of  interest  and  describes  the  type  of  resource 
information  that  is  desired.  For  example,  the  Internet 

uses  some  of  its  domain  names  to  identify  hosts;  queries  for 
address  resources  return  Internet  host  addresses. 

-  NAME  SERVERS  are  server  programs  which  hold  information  about 
the  domain  tree's  structure  and  set  information.  A  name 
server  may  cache  structure  or  set  information  about  any  part 
of  the  domain  tree,  but  in  general  a  particular  name  server 
has  com.plete  information  about  a  subset  of  the  domain  space, 
and  pointers  to  other  name  servers  that  can  be  used  to  lead  to 
information  from  any  part  of  the  domain  tree.  Name  servers 
know  the  parts  of  the  domain  tree  for  which  they  have  complete 
information;  a  name  server  is  said  to  be  an  AUTHORITY  for 
thuse  parts  of  the  name  space.  Authoritative  information  is 
organized  into  units  called  ZONES,  and  these  zones  can  be 
automatically  distributed  to  the  name  servers  which  provide 
redundant  service  for  the  data  in  a  zone. 

-  RESOLVERS  are  programs  that  extract  information  from  name 
se’'vers  in  response  to  client  requests.  Resolvers  must  be 
able  to  access  at  least  one  name  server  and  use  that  name 
server's  information  to  answer  a  query  directly,  or  pursue  the 
query  using  referrals  to  other  name  servers.  A  resolver  will 
typically  be  a  system  routine  that  is  directly  accessible  to 
user  programs;  hence  no  protocol  is  necessary  between  the 
resolver  and  the  user  program. 

These  three  components  roughly  correspond  to  the  three  layers  or  views 
of  the  domain  system: 

-  From  the  user' s  point  of  view,  the  domain  system  is  accessed 
through  a  simple  procedure  or  OS  call  to  a  local  resolver. 

The  domain  space  consists  of  a  single  tree  and  the  user  can 
request  information  from  any  section  of  the  tree. 

-  From  the  resolver's  point  of  view,  the  domain  system  is 
composed  of  an  unknown  number  of  name  servers.  Each  name 
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server  has  one  or  more  pieces  of  the  whole  domain  tree's  data, 
but  the  resolver  views  each  of  these  databases  as  essentially 
static . 

~  From  a  name  server's  point  of  view,  the  domain  system  consists 
of  separate  sets  of  local  information  called  zones.  The  name 
server  has  local  copies  of  some  of  the  zones.  The  name  server 
must  periodically  refresh  its  zones  from  master  copies  in 
local  files  or  foreign  name  servers.  The  name  server  must 
concurrently  process  queries  that  arrive  from  resolvers. 

In  the  interests  of  performance,  implementations  may  couple  these 
functions.  For  example,  a  resolver  on  the  same  machine  as  a  name  server 
might  share  a  database  consisting  of  the  the  zones  managed  by  the  name 
server  and  the  cache  managed  by  the  resolver. 

3 .  DOMAIN  NAME  SPACE  and  RESOURCE  RECORDS 

3.1.  Name  space  specifications  and  terminology 

The  domain  name  space  is  a  tree  structure.  Each  node  and  leaf  on  the 
tree  corresponds  to  a  resource  set  (which  may  be  empty) .  The  domain 
system  ma)<es  no  distinctions  between  the  uses  of  the  interior  nodes  and 
leaves,  and  this  memo  uses  the  term  "node”  to  refer  to  both. 

Each  node  has  a  label,  which  is  zero  to  63  octets  in  length.  Brother 
nodes  may  not  have  the  same  label,  although  the  same  label  can  be  used 
for  nodes  which  are  not  brothers.  One  label  is  reserved,  and  that  is 
the  null  (i.e.,  zero  length)  label  used  for  the  root. 

The  domain  name  of  a  node  is  the  list  of  the  labels  on  the  path  from  the 
node  to  the  toot  of  the  tree.  By  convention,  the  labels  that  compose  a 
domain  nam.e  ate  printed  or  read  left  to  right,  from  the  most  specific 
(lowest,  farthest  from  the  root)  to  the  least  specific  (highest,  closest 
to  the  root) . 

Internally,  programs  that  manipulate  domain  names  should  represent  them 
as  sequences  of  labels,  where  each  label  is  a  length  octet  followed  by 
an  octet  string.  Because  all  domain  names  end  at  the  root,  which  has  a 
null  string  for  a  label,  these  internal  represe.ntat  ions  can  use  a  length 
byte  of  zero  to  terminate  a  domain  name. 

By  convention,  domain  names  can  be  stored  with  arbitrary  case,  but 
domain  name  comparisons  for  all  present  domain  functions  are  done  in  a 
case-insensitive  manner,  assuming  an  ASCII  character  set,  and  a  high 
order  zero  bit.  This  means  that  you  are  free  to  create  a  node  with 
label  "A"  or  a  node  with  label  "a",  but  not  both  as  brothers;  you  could 
refer  to  either  using  "a"  or  "A".  When  you  receive  a  domain  name  or 
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label,  you  should  preserve  its  case.  The  rationale  for  this  choice  is 
tbat  we  may  soraeday  need  to  add  full  binary  domain  names  for  new 
services;  existing  services  would  not  be  changed. 

When  a  user  needs  to  type  a  domain  name,  the  length  of  each  label  is 
omitted  and  the  labels  are  separated  by  dots  (".") .  Since  a  complete 
irm.ain  narr.e  ends  with  the  root  label,  this  leads  to  a  printed  form  which 
er.is  in  a  dot.  We  use  this  property  to  distinguish  between: 

-  a  character  string  which  represents  a  co.mplete  domain  name 
(often  called  "absolute").  For  example,  "poneria.ISI.EDU." 

-  a  character  string  that  represents  the  starting  labels  of  a 
domain  name  which  is  incomplete,  and  should  be  completed  by 
local  software  using  knowledge  of  the  local  domain  (often 
called  "relative")  .  For  example,  "poneria"  used  in  the 
ISI.EDU  domai.n. 

Relative  names  are  either  taken  relative  to  a  well  known  origin,  or  to  a 
list  of  domains  used  as  a  search  list.  Relative  na.mes  appear  mostly  at 
'he  user  interface,  where  their  interpretation  varies  from 
im.plementat  ion  to  implementation,  and  in  master  files,  where  they  are 
relative  to  a  single  origin  domain  name.  The  most  common  interpretation 
u.ses  the  root  as  either  t.he  single  origin  or  as  one  of  the  members 

of  the  search  list,  so  a  multi-label  relative  name  is  often  one  where 
the  trailing  dot  has  been  omitted  to  save  typing. 

T;  simplify  irrplerrientat  ions,  the  total  nurrJoer  of  octets  that  represent  a 
i.rtain  name  (i.e.,  the  sum  of  all  label  octets  and  label  lengths)  is 
iimuted  to  255. 

.R  dtmain  is  identified  by  a  domain  nam.e,  and  consists  of  that  part  of 
domain  nam;e  space  that  is  at  or  below  the  domain  name  which 
:-.r.ec  i  f  ies  the  domain.  A  domain  is  a  subdomain  of  another  domain  if  it 
is  contained  within  t.hat  domain.  This  relationship  can  be  tested  by 
soetng  if  the  subdcm.ain's  name  ends  with  the  containing  domain's  name. 

F  t  examipie,  A.B.C.D  is  a  subdomain  of  B.C.D,  C.D,  D,  and  "  ". 

3.2.  Adm.inist  rat  ive  guidelines  on  use 

.As  a  matter  of  policy,  the  DNS  technical  specifications  do  not  mandate  a 
articular  tree  structure  or  rules  for  selecting  labels;  its  goal  is  to 
e  as  general  as  possible,  so  that  it  can  be  used  to  build  arbitrary 
applications.  In  particular,  the  system  was  designed  so  that  the  name 
space  did  not  have  to  be  organized  along  the  lines  of  network 
.00  ur.da  r  ies ,  name  servers,  etc.  The  rationale  for  this  is  not  that  the 
name  space  should  have  no  implied  semantics,  but  rather  that  the  choice 
'f  implied  serriantics  should  be  left  open  to  be  used  for  the  problem  at 
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hand,  and  that  different  parts  of  the  tree  c^n  have  different  implied 
semantics.  For  example,  the  IN-ADDR.ARPA  domain  is  organized  and 
distributed  by  network  and  host  address  because  its  role  is  to  translate 
from  network  or  host  numbers  to  names;  NetBIOS  domains  [RFC-1001,  RFC- 
1002]  are  flat  because  that  is  appropriate  for  that  application. 

However,  there  are  some  guidelines  that  apply  to  the  "normal"  parts  of 
the  name  space  used  for  bests,  mailboxes,  etc.,  that  will  make  the  name 
space  mere  uniform,  provide  for  growth,  and  minimize  problem.^  as 
software  is  converted  from  the  older  host  table.  The  political 
decisions  about  the  top  levels  of  the  tree  originated  in  RFC-920. 

Current  policy  for  the  top  levels  is  discussed  in  [RFC-1032] .  MILNET 
conversion  issues  are  covered  in  [RFC-1031] . 

fewer  domains  whic.h  will  eventually  be  broken  into  multiple  zones  should 
provide  branching  at  the  top  of  the  domain  so  that  the  eventual 
deco.m.position  can  be  done  without  rena-ming.  Node  labels  which  use 
special  characters,  leading  digits,  etc.,  a^e  likely  to  break  older 
software  which  depends  cn  more  restrictive  choices. 

3.3.  Technical  guidelines  on  use 

Before  the  DNS  can  be  used  to  hold  naming  information  for  some  kind  of 
object,  two  needs  must  be  met: 

-  A  convention  for  mapping  between  object  names  and  domain 
names.  This  describes  how  information  about  an  object  is 
accessed . 

-  RR  types  and  data  formats  for  describing  the  object. 

These  rules  can  be  quite  simple  or  fairly  complex.  Very  often,  the 
designer  must  take  into  account  existing  formats  and  plan  for  upward 
compatibility  for  existing  usage.  Multiple  mappings  or  levels  of 
mapping  may  be  required. 

For  hosts,  the  mapping  depends  on  the  existing  syntax  for  host  names 
which  is  a  subset  of  the  usual  text  representation  for  domain  names, 
together  with  RR  formats  for  describing  host  addresses,  etc.  Because  we 
need  a  reliable  inverse  mapping  from  address  to  host  name,  a  special 
mapping  for  addresses  into  the  IN-ADDR.ARPA  domain  is  also  defined. 

For  mailboxes,  the  mapping  is  slightly  more  complex.  The  usual  mail 
address  <local-part>@<mail-domain>  is  mapped  into  a  domain  name  by 
converting  <local-part>  into  a  single  label  (regardles  of  dots  it 
contains),  converting  <mail-domain>  into  a  dom-^in  name  using  the  usual 
text  format  for  domain  names  (dots  denote  label  breaks),  and 
concatenating  the  two  to  form  a  single  domain  name.  Thus  the  mailbe;-; 
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TMASTER@ SRI -NIC . ARPA  is  represented  as  a  domain  name  by 
TMASTER . SRI -NIC . ARPA .  An  appreciation  for  the  reasons  behind  this 
design  also  must  take  into  account  the  scheme  for  mail  exchanges  [RFC- 

974]  . 

The  typical  user  is  not  concerned  with  defining  these  rules,  but  should 
understand  that  they  usually  are  the  result  of  numerous  compromises 
oetween  desires  for  upward  compatibility  with  old  usage,  interactions 
retween  different  object  definitions,  and  the  inevitable  urge  to  add  new 
features  when  defining  the  rules.  The  way  the  DNS  is  used  to  support 
so.rne  object  is  often  more  crucial  than  the  restrictions  inherent  in  the 


3.4.  Example  name  space 

The  following  figure  shows  a  part  of  the  current  domain  name  space,  and 
is  used  in  many  examples  in  this  RFC.  Note  that  the  tree  is  a  very 
sm.all  subset  of  the  actual  name  space. 

I 
I 

-+ - + 

I  1 

EDU  ARPA 


+  - 

! 

MIL 


BRL  NOSC  DARPA  I  IN-ADDR  SRI-NIC  ACC 

I 

+ - + - + - + + 

i  I  I  II 

UCI  MIT  I  UDEL  YALE 

1  ISI 


+ - + - + 

1  I 

1 

1 

1  1 

LCS  ACHILLES 

1 

1 

1111  1 

1 

XX 

III]  1 

A  C  VAXA  VENERA  Mockapet r is 

Ir.  this  example,  the  root  d'^main  has  three  immediate  subdomains:  MIL, 
ED'J,  and  ARPA.  The  LCS.MIT.EDU  domain  has  one  immediate  subdomain  named 
XX.LCS.MIT.EDU.  All  of  the  leaves  are  also  domains. 

3.5.  Preferred  name  syntax 

The  DNS  specifications  attempt  to  be  as  general  as  possible  in  the  rules 
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for  constructing  domain  nam.es.  The  idea  is  that  the  name  of  any 
existing  object  can  be  expressed  as  a  domain  name  with  minimal  changes. 
However,  when  assigning  a  domain  name  for  an  object,  the  prudent  user 
will  select  a  name  which  satisfies  both  the  rules  of  the  domain  system 
and  any  existing  rules  for  the  object,  whether  these  rules  are  published 
or  im.plied  by  existing  programs. 

For  example,  when  naming  a  m.ail  domain,  the  user  should  satisfy  both  the 
rules  of  this  memo  and  those  in  RFC-822.  When  creating  a  new  host  name, 
the  old  rules  for  HOSTS.TXT  should  be  followed.  This  avoids  problems 
when  old  software  is  converted  to  use  domain  names. 

The  following  syntax  will  result  in  fewer  problems  with  many 
applications  that  use  domain  names  (e.g.,  mail,  TELNET) . 

<domain>  :  :=  <subdomain>  i  "  '' 

<subdomain>  ;;=  <label>  1  <subdomain>  <label> 

<label>  :;=  <letter>  (  [  <ldh-str>  ]  <let-dig>  ] 

<ldh-str>  ;:=  <let-dig-hyp>  (  <iet-dig-hyp>  <ldh-str> 

<let-dig-hyp>  ::=  <let-dig>  I 
<iet-dig>  ::=  <letter>  |  <digit> 

<letter>  : :=  any  one  of  the  52  alphabetic  characters  A  through  2  in 
upper  case  and  a  through  z  in  lower  case 

<digit>  :;=  any  one  of  the  ten  digits  0  through  9 

Note  that  while  upper  and  lower  case  letters  are  allowed  in  domain 
nam.es,  no  significance  is  attached  to  the  case.  That  is,  two  names  with 
the  same  spelling  but  different  case  are  to  be  treated  as  if  identical. 

The  labels  must  follow  the  rules  for  ARPANET  host  names.  They  must 
start  with  a  letter,  end  with  a  letter  or  digit,  and  have  as  interior 
characters  only  letters,  digits,  and  hyphen.  There  are  also  some 
restrictions  on  the  length.  Labels  must  be  63  characters  or  less. 

For  example,  the  following  strings  identify  hosts  in  the  Internet: 

A.ISI.ED'J  XX.LCS.MIT.EDU  SRI-NIC.ARPA 

3.6.  Resource  Records 

A  domain  name  identifies  a  node.  Each  node  has  a  set  of  resource 
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in:  crrr.ation,  which  may  be  empty.  The  set  of  resource  information 
associated  with  a  particular  name  is  composed  of  separate  resource 
reccrds  (RRs) .  The  order  of  RRs  in  a  set  is  not  significant,  and  need 
n.t  be  preserved  by  name  servers,  resolvers,  or  other  parts  of  the  DNS. 

When  we  talk,  about  a  specific  RR,  we  assume  it  has  the  following: 

cwner  which  is  the  domain  name  where  the  RR  is  found. 

'.yie  which  is  an  encoded  16  bit  value  that  specifies  the  type 

of  the  resource  in  this  resource  record.  Types  refer  to 
abstract  resources. 

This  memo  uses  the  following  types: 


crass 


A 

a  host  address 

CNA.ME 

identifies 

alias 

the  canonical  name  of  an 

HTNFO 

identifies 

the  CPU  and  OS  used  by  a  host 

MX 

identifies 

a  mail  exchange  for  the 

domain.  See  [RFC-974  for  details. 

NS 

the  authoritative  name  server  for  the  domain 
PTR 

a  pointer  to  another  part  of  the  domain  name  space 
SOA 

identifies  the  start  of  a  zone  of  authority] 

which  is  an  encoded  16  bit  value  which  identifies  a 
protocol  family  or  instance  of  a  protocol. 

This  memo  uses  the  following  classes: 

IN  the  Internet  system 

CH  the  Chaos  system 

which  is  the  time  to  live  of  th<=  RR .  This  field  is  a  32 
bit  integer  in  units  of  seconds,  an  is  primarily  used  by 
resolvers  when  they  cache  RRs.  The  TTL  describes  how 
long  a  RR  can  be  cached  before  it  should  be  discarded. 
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RDATA  which  is  the  type  and  sometimes  class  dependent  data 

which  describes  the  resource: 

A  For  the  IN  class,  a  32  bit  IP  address 

For  the  CH  class,  a  domain  name  followed 
by  a  16  bit  octal  Chaos  address. 

CNAME  a  domain  name. 

MX  a  16  bit  preference  value  (lower  is 

better)  followed  by  a  host  name  willing 
to  act  as  a  mail  exchange  for  the  owner 
domain . 

NS  a  host  name . 

PTR  a  domain  name. 

SOA  several  fields. 

The  owner  name  is  often  implicit,  "jcher  than  forming  an  integral  part 
of  the  RR.  For  example,  many  name  servers  internally  form  tree  or  hash 
structures  for  the  name  space,  and  chain  RRs  off  nodes.  The  remaining 
RR  parts  are  the  fixed  header  (type,  class,  TTL)  which  is  consistent  for 
all  RRs,  and  a  variable  part  (RDATA)  that  fits  the  needs  of  the  resource 
being  describe^. 

The  meaning  of  the  TTL  field  is  a  time  limit  on  how  long  an  RR  can  be 
kept  in  a  cache.  This  limit  does  not  apply  to  authoritative  data  in 
zones;  it  is  also  timed  out,  but  by  the  refreshing  policies  for  the 
zone.  The  TTL  is  assigned  by  the  administrator  for  the  zone  where  the 
data  originates.  While  short  TTLs  can  be  used  to  minimize  caching,  and 
a  zero  TTL  prohibits  caching,  the  realities  of  Internet  performance 
suggest  that  these  times  should  be  on  the  order  of  days  for  the  typical 
host.  If  a  change  can  be  anticipated,  the  TTL  can  be  reduced  prior  to 
the  change  to  minimize  inconsistency  during  the  change,  and  then 
increased  bac)c  to  its  former  value  following  the  change. 

The  data  in  the  RDATA  section  of  RRs  is  carried  as  a  combination  of 
binary  strings  and  domain  names.  The  domain  names  are  frequently  used 
as  "pointers"  to  other  data  in  the  DNS. 

3.6.1.  Textual  expression  of  RRs 

RRs  are  represented  in  binary  form  in  the  packets  of  the  DNS  protocol, 
and  are  usually  represented  in  highly  encoded  foim  when  stored  in  a  name 
server  or  resolver.  In  this  memo,  we  adopt  a  style  similar  to  that  used 
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in  master  files  in  order  to  show  the  contents  of  RRs .  In  this  format, 
most  HRs  are  shown  on  a  single  line,  although  continuation  lines  are 
possible  using  parentheses. 

The  start  of  the  line  gives  the  owner  of  the  RR.  If  a  line  begins  with 
a  blank,  then  the  owner  is  assumed  to  be  the  same  as  that  of  the 
previous  RR .  B] ank  lines  are  often  included  for  readability. 

Following  the  owner,  we  list  the  TTL,  type,  and  class  of  the  RR.  Class 
and  type  use  the  mnemonics  defined  above,  and  TTL  is  an  integer  before 
t.--  i-rera.  In  order  to  avoxa  amoxyulcy  in  pa_sing,  typo  an^ 

mnemionics  are  disjoint,  TTLs  are  integers,  and  the  type  mnemonic  is 
always  last.  The  IN  class  and  TTL  values  are  often  omitted  from  examples 
in  the  interests  of  clarity. 

The  resource  data  or  RDATA  section  of  the  RR  are  given  using  knowledge 
of  the  typical  representation  for  the  data. 

For  example,  we  might  show  the  RRs  carried  in  a  message  as: 


ISI.EDU. 

MX 

10  VENERA.ISI.EDU 

MX 

10  VAXA.ISI.EDU. 

VENERA. ISI .EDU. 

A 

128.9.0.32 

A 

10.1.0.52 

VAXA. ISI . EDU. 

A 

10.2.0.27 

A 

128.9.0.33 

The  MX  RRs  have  an  RDATA  section  which  consists  of  a  16  bit  number 
followed  by  a  domain  name.  The  address  RRs  use  a  standard  IP  address 
format  to  contain  a  32  bit  internet  address. 


This  example  shows  six  RRs,  with  two  RRs  at  each  of  three  domain  names. 
Similarly  we  might  see: 


XX . LCS .MIT ,EDU.  IN  A 

CH  A 


10.0.0.44 
MIT.EDU.  2420 


This  example  shows  two  addresses  for  XX.LCS.MIT.EDU,  each  of  a  different 
class  . 


3.6.2.  Aliases  and  canonical  names 


In  existing  systems,  hosts  and  other  resources  often  have  several  names 
that  identify  the  same  resource.  For  example,  the  names  C. ISI.EDU  and 
USC-ISIC . ARPA  both  identify  the  same  host.  Similarly,  in  the  case  of 
m.ailboxes,  many  organizations  provide  many  names  that  actually  go  to  the 
same  mailbox;  for  example  Mockapetris0C.ISI.EDU,  Mockapetri30B.ISI.EDU, 
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and  PVMSISI.EDU  all  go  to  the  same  mailbox  (although  the  mechanism 
behind  this  is  somewhat  complicated) . 

Most  of  these  systems  have  a  notion  that  one  of  the  equivalent  set  of 
names  is  the  canonical  or  primary  name  and  all  others  are  aliases. 

The  domain  system  provides  such  a  feature  using  the  canonical  name 
(CNAME)  RR.  A  CNAME  RR  identifies  its  owner  name  as  an  alias,  and 
specifies  the  corresponding  canonical  name  in  the  RDATA  section  of  the 
RR.  If  a  CNAME  PR  is  present  at  a  node,  no  other  data  should  be 
present;  this  ensures  that  the  data  for  a  canonical  name  and  its  aliases 

used  without  chec)clng  with  an  authoritative  server  for  other  RR  types. 

CNAME  RRs  cause  special  action  in  DNS  software.  When  a  name  server 
fails  to  find  a  desired  RR  in  the  resource  set  associated  with  the 
domain  name,  it  chec)<s  to  see  if  the  resource  set  consists  of  a  CNAME 
record  with  a  matching  class.  If  so,  the  name  server  includes  the  CNAME 
record  in  the  response  and  restarts  the  query  at  the  domain  name 
specified  in  the  data  field  of  the  CNAME  record.  The  one  exception  to 
this  rule  is  that  queries  which  match  the  CNAME  type  are  not  restarted. 

For  example,  suppose  a  name  server  was  processing  a  query  with  for  USC- 
ISIC.ARPA,  asking  for  type  A  information,  and  had  the  following  resource 
records : 


USC-ISIC. ARPA 

IN 

CNAME 

C. 

ISI.EDU 

C. ISI .EDU 

IN 

A 

10 

CM 

if) 

O 

O 

Both  of  these  RRs  would  be  returned  in  the  response  to  the  type  A  query, 
while  a  type  CNAME  or  *  query  should  return  just  the  CNAME. 

Domain  names  in  RRs  which  point  at  another  name  should  always  point  at 
the  primary  name  and  not  the  alias.  This  avoids  extra  indirections  in 
accessing  information.  For  example,  the  address  to  name  RR  for  the 
above  host  should  be: 

52 . 0 . 0 . 10 . IN-ADDR. ARPA  IN  PTR  C. ISI.EDU 

rather  than  pointing  ct  USC-ISIC. ARPA.  Of  course,  by  the  robustness 
principle,  domain  software  should  not  fail  when  presented  with  CNAME 
chains  or  loops;  CNAME  chains  should  be  followed  and  CNAME  loops 
signalled  as  an  error. 

3.7.  Queries 

Queries  are  messages  which  may  be  sent  to  a  name  server  to  provoke  a 
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response.  In  the  Internet,  queries  are  carried  in  UDP  datagrams  or  over 
TCP  connections.  The  response  by  the  name  server  either  answers  the 
question  posed  in  the  query,  refers  the  requester  to  another  set  of  name 
servers,  or  signals  some  error  condition. 

In  general,  the  user  does  not  generate  queries  directly,  but  instead 
makes  a  request  to  a  resolver  which  in  turn  sends  one  or  more  queries  to 
name  servers  and  deals  with  the  error  conditions  and  referrals  that  may 
result.  Of  course,  the  possible  questions  which  can  be  asked  in  a  query 
does  shape  the  kind  of  service  a  resolver  can  provide. 

DNS  queries  and  responses  are  carried  in  a  standard  message  format.  The 
message  format  has  a  header  containing  a  number  of  fixed  fields  which 
are  always  present,  and  four  sections  which  carry  query  parameters  and 
RRs  . 


The  most  important  field  in  the  header  is  a  four  bit  field  called  an 
opcode  which  separates  different  queries.  Of  the  possible  16  values, 
one  (standard  query)  is  part  of  the  official  protocol,  two  (inverse 
cjuery  and  status  query)  are  options,  one  (completion)  is  obsolete,  and 
the  rest  are  unassigned. 

The  four  sections  are; 


Question 

Answer 

Authority 


Additional 


Carries  the  query  name  and  other  query  parameters. 

Carries  RRs  which  directly  answer  the  query. 

Carries  RRs  which  describe  other  authoritative  servers. 
May  optionally  carry  the  SOA  RR  for  the  authoritative 
data  in  the  answer  section. 

Carries  RRs  which  may  be  helpful  in  using  the  RRs  in  the 
other  sections. 


Note  that  the  content,  but  not  the  format,  of  these  sections  varies  with 
header  opcode. 

3.7.1.  Standard  queries 

A  standard  query  specifies  a  target  domain  name  (QNAME) ,  query  type 
(QTYPE) ,  and  query  class  (QCLASS)  and  asks  for  RRs  which  match.  This 
type  of  query  makes  up  such  a  vast  majority  of  DNS  queries  that  we  use 
the  term  "query"  to  mean  standard  query  unless  otherwise  specified.  The 
QTYPE  and  QCLASS  fields  are  each  16  bits  long,  and  are  a  superset  of 
defined  and  classes. 
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The  QTYPE  field  may  contain: 

<any  type>  matches  just  that  type,  (e.g..  A,  PTR) . 

AXFR  special  zone  transfer  QTYPE. 

MAILS  matches  all  mail  box  related  RRs  (e.g.  MB  and  MG) . 

*  matches  all  RR  types. 

The  QCLASS  field  may  contain: 

<any  class>  matches  just  that  class  (e.g.,  IN,  CH) . 

*  matches  aLL  RR  classes. 

Using  the  query  domain  name,  QTYPE,  and  QCLASS,  the  name  server  looks 
for  matching  RRs.  In  addition  to  relevant  records,  the  name  server  may 
return  RRs  that  point  toward  a  name  server  that  has  the  desired 
information  or  RRs  that  are  expected  to  be  useful  in  interpreting  the 
relevant  RRs.  For  example,  a  name  server  that  doesn't  have  ♦'he 
requested  information  may  know  a  name  server  that  does;  a  name  server 
that  returns  a  domain  name  in  a  relevant  RR  may  also  return  the  RR  that 
binds  that  domain  name  to  an  address. 

For  example,  a  mailer  tying  to  send  mail  to  Mockapetris@ISI.EDU  might 
ask  the  resolver  for  mail  information  about  ISI.EDU,  resulting  in  a 
query  for  QNAME=ISI . EDU,  QTYPE=MX,  QCLASS=IN.  The  response's  answer 
section  would  be: 

ISI.EDU.  MX  10  VENERA.ISI.EDU. 

MX  10  VAXA.ISI.EDU. 

while  the  additional  section  might  be: 

VAXA.ISI.EDU.  A  10.2.0.27 

A  128.9.0.33 

VENERA.ISI.EDU.  A  10.1.0.52 

A  128.9.0.32 

Because  the  server  assumes  that  if  the  requester  wants  mail  exchange 
information,  it  will  probably  want  the  addresses  of  the  mail  exchanges 
soon  afterward. 

Note  that  the  QCLASS=*  construct  requires  special  interpretation 
regarding  authority.  Since  a  particular  name  server  may  not  know  all  of 
the  classes  available  in  the  domain  system,  it  can  never  know  if  it  is 
authoritative  for  all  classes.  Hence  responses  to  QCLASS=*  queries  can 
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never  be  authoritative. 

3.7.2.  Inverse  queries  (Optional) 

Name  servers  may  also  support  inverse  queries  that  map  a  particular 
resource  to  a  domain  name  or  domain  names  that  have  that  resource.  For 
example,  while  a  standard  query  might  map  a  domain  name  to  a  SOA  RR,  the 
corresponding  inverse  query  might  map  the  SOA  RR  back,  to  the  domain 
name  . 


Imple'^ent  at  ion  of  this  service  is  optional  in  a  name  server,  but  all 
name  servers  must  at  ieaot  be  able  to  understand  an  inverse  query 
message  and  return  a  net-implemented  error  response. 

The  domain  system  cannot  guarantee  the  completeness  or  uniqueness  of 
inverse  queries  because  the  domain  system  is  organized  by  domain  name 
rather  than  by  host  address  or  any  other  resource  type.  Inverse  queries 
are  primarily  useful  for  debugging  and  database  maintenance  activities. 

Inverse  queries  may  not  return  the  proper  TTL,  and  do  not  indicate  cases 
where  the  identified  RR  is  one  of  a  set  (for  example,  one  address  for  a 
host  having  multiple  addresses) .  Therefore,  the  RRs  returned  in  inverse 
queries  should  never  be  cached. 

Inverse  queries  are  NOT  an  acceptable  method  for  mapping  host  addresses 
to  host  names;  use  the  IN-ADDR.ARPA  domain  instead. 

A  detailed  discussion  of  inverse  queries  is  contained  in  [RFC-1035] . 

3.8.  Status  queries  (Experimental) 

To  be  defined. 

3.9.  Completion  queries  (Obsolete) 

The  optional  completion  services  described  in  RFCs  882  and  883  have  been 
deleted.  Redesigned  services  may  become  available  in  the  future,  or  the 
opcodes  may  be  reclaimed  for  other  use. 

4 .  NAME  SERVERS 

4.1.  Introduction 

Name  servers  are  the  repositories  of  information  that  make  up  the  domain 
database.  The  database  is  divided  up  into  sections  called  zones,  which 
are  distributed  among  the  na.me  servers.  While  name  servers  can  have 
several  optional  functions  and  sources  of  data,  the  essential  task  of  a 
name  server  is  to  answer  queries  using  data  in  its  zones.  By  design. 
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name  servers  can  answer  queries  in  a  simple  manner;  the  response  can 
always  be  generated  using  only  local  data,  and  either  contains  the 
answer  to  the  question  or  a  referral  to  other  name  servers  "closer"  to 
the  desired  information. 

A  given  zone  will  be  available  from  several  name  servers  to  insure  its 
availability  in  spite  of  host  or  communication  link  failure.  By 
administrative  fiat,  we  require  every  zone  to  be  available  on  at  least 
two  servers,  and  many  zones  have  more  redundancy  than  that. 

A  given  name  server  will  typically  support  one  or  more  zones,  but  this 
gives  it  authoritative  information  about  only  a  small  section  of  t.he 
domain  tree.  It  may  also  have  some  cached  non-authoritative  data  about 
ether  parts  of  the  tree.  The  name  server  marks  its  responses  to  queries 
so  that  the  requester  can  tell  whether  the  response  comes  from 
authoritative  data  or  not. 

4.2.  How  the  database  is  divided  into  zones 

The  domain  database  is  partitioned  in  two  ways:  by  class,  and  by  "cuts" 
made  in  the  name  space  between  nodes . 

The  class  partition  is  simple.  The  database  for  any  class  is  organized, 
delegated,  and  maintained  separately  from  all  other  classes.  Since,  by 
convention,  the  name  spaces  are  the  same  for  all  classes,  the  separate 
classes  can  be  thought  of  as  an  array  of  parallel  namespace  trees.  Note 
that  the  data  attached  to  nodes  will  be  different  for  these  different 
parallel  classes.  The  most  common  reasons  for  creating  a  new  class  are 
the  necessity  for  a  new  data  format  for  existing  types  or  a  desire  for  a 
separately  managed  version  of  the  existing  name  space. 

Within  a  class,  "cuts"  in  the  name  space  can  be  made  between  any  two 
adjacent  nodes.  After  ail  cuts  are  made,  each  group  of  connected  name 
space  is  a  separate  zone.  The  zone  is  said  to  be  authoritative  for  all 
names  in  the  connected  region.  Note  that  the  "cuts"  in  the  name  space 
may  be  in  different  places  for  different  classes,  the  name  servers  may 
be  different,  etc. 

These  rules  mean  that  every  zone  has  at  least  one  node,  and  hence  domain 
name,  for  which  it  is  authoritative,  and  all  of  the  nodes  in  a 
particular  zone  are  connected.  Given,  the  tree  structure,  every  zone 
has  a  highest  node  which  is  closer  to  the  root  than  any  other  node  in 
the  zone.  The  name  of  this  node  is  often  used  to  identify  the  zone. 

It  would  be  possible,  though  not  particularly  useful,  to  partition  the 
name  space  so  that  each  domain  name  was  in  a  separate  zone  or  so  that 
all  nodes  were  in  a  single  zone.  Instead,  the  database  is  partitioned 
at  points  where  a  particular  organization  wants  to  take  over  control  of 
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a  subtree.  Once  an  organization  controls  its  own  zone  it  can 
unilaterally  change  the  data  in  the  zone,  grow  new  tree  sections 
connected  to  the  zone,  delete  existing  nodes,  or  delegate  new  subzones 
under  its  zone. 

If  the  organization  has  substructure,  it  may  want  to  make  further 
internal  partitions  to  achieve  nested  delegations  of  name  space  control. 
In  some  cases,  such  divisions  are  made  purely  to  m.ake  database 
maintenance  more  convenient. 

4.2.1.  Technical  considerations 

The  data  that  describes  a  zone  has  four  major  parts; 

-  Authoritative  data  for  all  nodes  within  the  zone. 

-  Data  that  defines  the  top  node  of  the  zone  (can  be  thought  of 
as  part  of  the  authoritative  data) . 

-  Data  that  describes  delegated  subzones,  i.e.,  cuts  around  the 
bottom  of  the  zone. 

-  Data  that  allows  access  to  name  servers  for  subzones 
(sometimes  called  "glue"  data) . 

All  of  this  data  is  expressed  in  the  form  of  RRs,  so  a  zone  can  be 
completely  described  in  terms  of  a  set  of  RRs.  Whole  zones  can  be 
transferred  between  name  servers  by  transferring  the  RRs,  either  carried 
in  a  series  of  messages  or  by  FTPing  a  master  file  which  is  a  textual 
representation . 

The  authoritative  data  for  a  zone  is  simply  all  of  the  RRs  attached  to 
all  of  the  nodes  from  the  top  node  of  the  zone  down  to  leaf  nodes  or 
nodes  above  cuts  around  the  bottom  edge  of  the  zone. 

Though  logically  part  of  the  authoritative  data,  the  RRs  that  describe 
the  top  node  of  the  zone  are  especially  important  to  the  zone' s 
rrianagement  .  These  RRs  are  of  two  types:  name  server  RRs  that  list,  one 
per  RR,  all  of  the  servers  for  the  zone,  and  a  single  SOA  RR  that 
describes  zone  management  parameters. 

The  RRs  that  describe  cuts  around  the  bottom  of  the  zone  are  NS  RRs  that 
name  the  servers  for  the  subzones.  Since  the  cuts  are  between  nodes, 
these  RRs  are  NOT  part  of  the  authoritative  data  of  the  zone,  and  should 
be  exactly  the  same  as  the  corresponding  RRs  in  the  top  node  of  the 
subzone.  Since  name  servers  are  always  associated  with  zone  boundaries, 
NS  RRs  are  only  found  at  nodes  which  are  the  top  node  of  some  zone.  In 
the  data  that  makes  up  a  zone,  NS  RRs  are  found  at  the  top  node  of  the 
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zone  (and  are  authoritative)  and  at  cuts  around  the  bottom  of  the  zone 
(where  they  are  not  authoritative),  but  never  in  between. 

One  of  the  goals  of  the  zone  structure  is  that  any  zone  have  all  the 
data  required  to  set  up  communications  with  the  name  servers  for  any 
subzones.  That  is,  parent  zones  have  all  the  information  needed  to 
access  servers  for  their  children  zones.  The  NS  RRs  that  name  the 
servers  for  subzones  are  often  not  enough  for  this  taslc  since  they  name 
the  servers,  but  do  not  give  their  addresses.  In  particular,  if  the 
name  of  the  name  server  is  itself  in  the  subzone,  we  could  be  faced  with 
the  situation  where  the  NS  RRs  tell  us  that  in  order  to  learn  a  name 
server's  address,  we  should  contact  the  server  using  the  address  we  wish 
to  learn.  To  fix  this  problem,  a  zone  contains  "glue"  RRs  which  are  not 
part  of  the  authoritative  data,  and  are  address  RRs  for  the  servers. 
These  RRs  are  only  necessary  if  the  name  server's  name  is  "below"  the 
cut,  and  are  only  used  as  part  of  a  referral  response. 

4.2.2.  Administrative  considerations 

When  some  organization  wants  to  control  its  own  domain,  the  first  step 
is  to  identify  the  proper  parent  zone,  and  get  the  parent  zone's  owners 
to  agree  to  the  delegation  of  control.  While  there  are  no  particular 
technical  constraints  dealing  with  where  in  the  tree  this  can  be  done, 
there  are  some  administrative  groupings  discussed  in  [RFC-1032]  which 
deal  with  top  level  organization,  and  middle  level  zones  are  free  to 
create  their  own  rules.  For  example,  one  university  might  choose  to  use 
a  single  zone,  while  another  might  choose  to  organize  by  subzones 
dedicated  to  individual  departments  or  schools.  [RFC-1033]  catalogs 
available  DNS  software  an  discusses  administration  procedures. 

Once  the  proper  name  for  the  new  subzone  is  selected,  the  new  owners 
should  be  required  to  demonstrate  redundant  name  server  support .  Note 
that  there  is  no  requirement  that  the  servers  for  a  zone  resid^'  in  a 
host  which  has  a  name  in  that  domain.  In  many  cases,  a  zone  wi.l  be 
more  accessible  to  the  internet  at  large  if  its  servers  are  widely 

stributed  rather  than  being  within  the  physical  facilities  controlled 
by  the  same  organization  that  manages  the  zone.  For  example,  in  the 
current  DNS,  one  of  the  name  servers  for  the  United  Kingdom,  or  UK 
domain,  is  found  in  the  US.  This  allows  US  hosts  to  get  UK  data  without 
using  limited  transatlantic  bandwidth. 

As  the  last  installation  step,  the  delegation  NS  RRs  and  glue  RRs 
necessary  to  ma)ce  the  delegation  effective  should  be  added  to  the  parent 
zone .  The  administrators  of  both  zones  should  insure  that  the  NS  and 
glue  RRs  which  marie  both  sides  of  the  cut  are  consistent  and  remain  so. 

4.3.  Name  server  internals 
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1.3.1,  Queries  and  responses 

T;.r'  !  ;  incipal  activity  of  name  servers  is  to  answer  standard  queries. 

C  t;.  tr.e  query  and  its  response  are  carried  in  a  standard  message  format 
wi.i.in  is  described  in  [RFC-lOuS].  The  query  contains  a  QTYPE,  QCLASS, 
Q.V.AME,  whic.h  de.scribe  the  types  a.nd  classes  of  desired  information 
aci  the  name  of  interest. 

T.h-^  w.;iy  'hit  ".he  na.me  server  answers  the  query  depe.nds  upon  whether  it 

.t-ia'i.tg  ..n  recursive  mode  or  not: 

-  The  sirr.piest  mode  for  the  server  is  non-recursive,  since  it 
can  a.nswer  queries  using  only  local  inf  ormat  i-on :  the  response 
contains  an  error,  the  answer,  or  a  referral  tc  some  other 
server  "closer"  to  the  answer.  All  name  servers  must 
i.mple.ment  non-recursive  queries. 

-  The  simplest  mode  for  the  client  is  recursive,  since  in  this 
mode  the  name  server  acts  in  the  role  of  a  resolver  and 
returns  either  an  error  or  the  answer,  but  never  referrals. 

This  service  is  optional  in  a  name  server,  and  the  name  server 
may  also  choose  to  restrict  the  clients  which  can  use 
recursive  mode. 

Recursive  service  is  helpful  in  several  situations: 

-  a  relatively  simple  requester  that  lacks  the  ability  to  use 
anything  other  than  a  direct  answer  to  the  question. 

-  a  request  that  needs  to  cross  protocol  or  other  boundaries  and 
can  be  sent  to  a  server  which  can  act  as  intermediary. 

-  a  network  where  we  want  to  concentrate  the  cache  rather  than 
having  a  separate  cache  for  each  client. 

•Ncr.-recursive  service  is  appropriate  if  the  requester  is  capable  of 
pur.suing  referrals  and  interested  in  information  which  will  aid  future 
requests . 

The  use  of  recursive  mode  is  limited  to  cases  where  both  the  client  and 
the  name  server  agree  to  its  use.  The  agreement  is  negotiated  through 
"he  u.3e  of  two  bits  in  query  and  response  messages: 

-  The  recursion  available,  or  RA  bit,  is  set  or  cleared  by  a 
name  server  in  all  responses.  The  bit  is  true  if  the  name 
server  is  willing  to  provide  recursive  service  for  the  client, 
regardless  of  whether  the  client  requested  recursive  service. 

That  is,  PA  signals  availability  rather  than  use. 
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-  Queries  contain  a  bit  called  recursion  desired  or  RD .  This 
bit  specifies  specifies  whether  the  requester  wants  recursive 
service  for  this  query.  Clients  may  request  recursive  service 
from  any  name  server,  though  they  should  depend  upon  receiving 
it  only  from  servers  which  have  previously  sent  an  RA,  or 
servers  which  have  agreed  to  provide  service  through  private 
agreement  or  som.e  other  m.eans  outside  of  the  DNS  protocol. 

The  recursive  mode  occurs  when  a  query  with  RD  set  arrives  at  a  server 
which  is  willing  to  provide  recursive  service;  the  client  can  verify 
that  recursive  mode  was  used  by  checking  that  both  RA  and  RD  are  set  in 
the  reply.  Note  that  the  name  server  should  never  perform  recursive 
service  unless  asked  via  RD,  since  this  interferes  with  trouble  shooting 
of  name  servers  and  their  databases. 

If  recursive  service  is  requested  and  available,  the  recursive  response 
to  a  query  will  be  one  of  the  following; 

-  The  answer  to  the  q'uery,  possibly  preface  by  one  or  more  CNAME 
RRs  that  specify  aliases  encountered  on  the  way  to  an  answer. 

-  A  name  error  indicating  that  the  name  does  not  exist.  This 
may  include  CNAME  RRs  that  indicate  that  the  original  query 
name  was  an  alias  for  a  name  which  does  not  exist. 

-  A  temporary  error  indication. 

If  recursive  service  is  not  requested  or  is  not  available,  the  non¬ 
recursive  response  will  be  one  of  the  following; 

-  An  authoritative  name  error  indicating  that  the  name  does  not 
exist . 

-  A  temporary  error  indication. 

-  Some  combination  of; 

RRs  that  answer  the  question,  together  with  an  indication 
whether  the  data  comes  from  a  zone  or  is  cached. 

A  referral  to  name  servers  which  have  zones  which  are  closer 
ancestors  to  the  name  than  the  server  sending  the  reply. 

-  RRs  that  the  name  server  thinks  will  prove  useful  to  the 
requester . 
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4.3.2.  Alg:rith:n 

The  actual  algorithm  used  by  the  name  server  will  depend  on  the  local  OS 

a.u  :i  i.ata  structures  used  to  store  RRs .  The  following  algorithm  assumes 
that  the  RRs  are  organized  in  several  tree  structures,  one  for  each 
z:;.e,  and  another  for  the  cache: 

1.  Set  or  clear  the  value  of  recursion  available  in  the  response 
depending  on  whether  the  name  server  is  willing  to  provide 
recursive  service.  If  recursive  service  is  available  and 
requested  via  the  RD  bit  in  the  query,  go  to  step  5, 
otherwise  step  2. 

2.  Search  the  available  zones  for  the  zone  which  is  the  nearest 
ancestor  to  QNAME .  If  such  a  zone  is  found,  go  to  step  3, 
otherwise  step  4. 

3.  Start  matching  down,  label  by  label,  in  the  zone.  The 
rr.atching  process  can  terminate  several  ways: 

a.  If  the  whole  of  QNAME  is  matched,  we  have  found  the 
node  . 

If  the  data  at  the  node  is  a  CNAME,  and  QTYPE  doesn't 
match  CNAME,  copy  the  CNAME  RR  into  the  answer  sectxon 
of  the  response,  change  QNAME  to  the  canonical  name  in 
the  CNAME  RR,  and  go  back  to  step  1  . 

Otherwise,  copy  all  RRs  which  match  QTYPE  into  the 
answer  section  and  go  to  step  S. 

b.  If  a  match  would  take  us  out  of  the  authoritative  data, 
we  have  a  referral.  This  happens  when  we  encounter  a 
node  with  NS  RRs  marking  cuts  along  the  bottom  of  a 
zone  . 

Copy  the  NS  RRs  for  the  subzone  into  the  authority 
section  of  the  reply.  Put  whatever  addresses  are 
available  into  the  additional  section,  using  glue  RRs 
if  the  addresses  are  not  available  from  authoritative 
data  or  the  cache.  Go  to  step  4. 

c.  If  at  some  label,  a  match  is  impossible  (i.e.,  the 

corresponding  label  does  not  exist) ,  look  to  see  if  a 
the  label  exists. 

If  the  label  does  not  exist,  check  whether  the  name 

we  are  looking  for  is  the  original  QNAME  in  the  query 
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or  a  name  we  have  followed  due  to  a  CNAME .  If  the  name 
is  original,  set  an  authoritative  name  error  in  the 
response  and  exit.  Otherwise  just  exit. 

If  the  "*"  label  does  exist,  match  RRs  at  taat  node 
against  QTYPE.  If  any  match,  copy  them  into  the  answer 
section,  but  set  the  owner  of  the  RR  to  be  and 

not  the  node  with  the  label.  Go  to  step  6. 

4.  Start  matching  down  in  the  cache.  If  QNAME  is  found  in  the 
cache,  copy  all  RRs  attached  to  it  that  match  QTYPE  into  the 
answer  section.  If  there  was  no  delegation  from 
authoritative  data,  look  for  the  best  one  from  the  cache,  and 
put  it  in  the  authority  section.  Go  to  step  6. 

5.  Using  the  local  resolver  or  a  copy  of  its  algorithm  (see 
resolver  section  of  this  memo)  to  answer  the  query.  Store 
the  results,  including  any  intermediate  CNAMEs,  in  the  answer 
section  of  the  response. 

6.  Using  local  data  only,  attempt  to  add  other  RRs  which  may  be 
useful  to  the  additional  section  of  the  query.  Exit. 

4.3.3.  Wildcards 

In  the  previous  algorithm,  special  treatment  was  given  to  RRs  with  owner 
names  starting  with  the  label  Such  RRs  are  called  wildcards. 

Wildcard  RRs  can  be  thought  of  as  instructions  for  synthesizing  RRs. 

When  the  appropriate  conditions  are  met,  the  name  server  creates  RRs 
with  an  owner  name  equal  to  the  query  name  and  contents  talcen  from  the 
wildcard  RRs . 

This  facility  is  most  often  used  to  create  a  zone  which  will  be  used  to 
forward  mail  from  the  Internet  to  some  other  mail  system.  The  general 
idea  is  that  any  name  in  that  zone  which  is  presented  to  server  in  a 
query  will  be  assumed  to  exist,  with  certain  properties,  unless  explicit 
evidence  exists  to  the  contrary.  Note  that  the  use  of  the  term  zone 
here,  instead  of  domain,  is  intentional;  such  defaults  do  not  propagate 
across  zone  boundaries,  although  a  subzone  may  choose  to  achieve  that 
appearance  by  setting  up  similar  defaults. 

The  contents  of  the  wildcard  RRs  follows  the  usual  rules  and  formats  for 
RRs.  The  wildcards  in  the  zone  have  an  owner  name  that  controls  the 
query  nam.es  they  will  match.  The  owner  name  of  the  wildcard  RRs  is  of 
Che  form  "  *  .  <anydomain>'',  where  <anydomain>  is  any  domain  name. 
<anydomain>  should  not  contain  other  *  labels,  and  should  be  in  tlie 
authoritative  data  of  che  zone.  The  wildcards  potentially  apply  to 
descendants  of  <anydomia in> ,  but  not  to  <anydoraain>  itself.  Another  way 
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to  look  at  this  is  that  the  label  always  matches  at  least  one  whole 

label  and  sometimes  m.ore,  but  always  whole  labels. 

Wildcard  RRs  do  not  apply: 

-  When  the  query  is  in  another  zone.  That  is,  delegation  cancels 
the  wildcard  defaults. 

-  When  the  query  name  or  a  name  between  the  wildcard  domain  and 
the  query  name  is  know  to  exist.  For  example,  if  a  wildcard 
.RR  .has  an  owner  nam.e  of  ”*.X”,  and  the  zone  also  contains  RRs 
attached  to  B.X,  the  wildcards  would  apply  to  queries  for  name 
Z.X  (presuming  there  is  no  explicit  information  for  Z.X),  but 
not  to  B.X,  A. B.X,  or  X. 

A  *  label  appearing  in  a  query  name  has  no  special  effect,  but  can  be 
used  to  test  for  wildcards  in  an  authoritative  zone;  such  a  query  is  the 
only  way  to  get  a  response  containing  RRs  with  an  owner  name  with  *  in 
it.  The  result  of  such  a  query  should  not  be  cached. 

Note  that  the  contents  of  the  wildcard  RRs  are  not  modified  when  used  to 
synthesize  RRs. 

To  illustrate  the  use  of  wildcard  RRs,  suppose  a  large  company  with  a 
large,  non-IP/TCP,  network  wanted  to  create  a  mail  gateway.  If  the 
company  was  called  X.COM,  and  IP/TCP  capable  gateway  machine  was  called 
A.X.COM,  the  following  RRs  might  be  entered  into  the  COM  zone: 


X.COM 

MX 

10 

A.X.COM 

* .X.COM 

MX 

10 

A . X . COM 

A.X.COM 

A 

1.2.3, 

.4 

A . X . COM 

MX 

10 

A . X . COM 

* . A . X . COM 

MX 

10 

A . X . COM 

This  would  cause  any  MX  query  for  any  domain  name  ending  in  X.COM  to 
return  an  MX  RR  pointing  at  A.X.COM.  Two  wildcard  RRs  are  required 
since  the  effect  of  the  wildcard  at  *. X.COM  is  inhibited  in  the  A.X.COM 
subtree  by  the  explicit  data  for  A.X.COM.  Note  also  that  the  explicit 
MX  data  at  X.COM  and  A.X.COM  is  required,  and  that  none  of  the  RRs  above 
would  match  a  query  name  of  XX.COM. 

4.3.4.  Negative  response  caching  (Optional) 

The  DNS  provides  an  optional  service  which  allows  name  servers  to 
distribute,  and  resolvers  to  cache,  negative  results  with  TTLs .  For 
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example,  a  name  server  can  distribute  a  TTL  along  with  a  name  error 
indication,  and  a  resolver  receiving  such  information  is  allowed  to 
assume  that  the  name  does  not  exist  during  the  TTL  period  without 
consulting  authoritative  data.  Similarly,  a  resolver  can  make  a  query 
with  a  QTYPE  which  matches  multiple  types,  and  cache  the  fact  that  some 
of  the  types  are  not  present. 

This  feature  can  be  particularly  imp'^’'tant  in  a  system  which  implements 
naming  shorthands  that  use  search  lists  beacuse  a  popular  shorthand, 
which  happens  to  require  a  suffix  toward  the  end  of  the  search  lisu, 
will  generate  multiple  name  errors  whenever  it  is  used. 

The  method  is  that  a  name  server  may  add  an  SOA  RR  to  the  additional 
section  of  a  response  when  that  response  is  authoritative.  The  SOA  must 
be  that  of  the  zone  which  was  the  source  of  the  authoritative  data  in 
the  answer  section,  or  name  error  if  applicable.  The  MINIMUM  field  of 
the  SOA  controls  the  length  of  time  that  the  negative  result  may  be 
cached , 

Note  that  in  some  circumstances,  the  answer  section  may  contain  multiple 
owner  names.  In  this  case,  the  SOA  mechanism  should  only  be  used  for 
the  data  which  matches  QNAME,  which  is  the  only  authoritative  data  in 
this  section. 

Name  servers  and  resolvers  should  never  attempt  to  add  SOAs  to  the 
additional  section  of  a  non-authoritative  response,  or  attempt  to  infer 
results  which  are  not  directly  stated  in  an  authoritative  response. 

There  are  several  reasons  for  this,  including:  cached  information  isn't 
usually  enough  to  match  up  RRs  and  their  zone  names,  SOA  RRs  may  be 
cached  due  to  direct  SOA  queries,  and  name  servers  are  not  required  to 
output  the  SOAs  in  the  authority  section. 

This  feature  is  optional,  although  a  refined  version  is  expected  to 
become  part  of  the  standard  protocol  in  the  future.  Name  servers  are 
not  required  to  add  the  SOA  RRs  in  all  authoritative  responses,  nor  are 
resolvers  required  to  cache  negative  results.  Both  are  recommended. 

All  resolvers  and  recursive  name  servers  are  required  to  at  least  be 
able  to  ignore  the  SOA  RR  when  it  is  present  in  a  response. 

Some  experiments  have  also  been  proposed  which  will  use  this  feature. 

The  idea  is  that  if  cached  data  is  known  to  come  from  a  particular  zone, 
and  if  an  authoritative  copy  of  the  zone's  SOA  is  obtained,  and  if  the 
zone's  SERIAL  has  not  changed  since  the  data  was  cached,  then  the  TTL  of 
the  cached  data  can  be  reset  to  the  zone  MINIMUM  value  if  it  is  smaller. 
This  usage  is  mentioned  for  planning  purposes  only,  and  is  not 
recommended  as  yet . 
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4.3.5.  Zone  maintenance  and  transfers 

Part  of  the  job  of  a  zone  administrator  is  to  maintain  the  zones  at  all 
of  the  name  servers  which  are  authoritative  for  the  zone.  When  the 
inevitable  changes  are  made,  they  must  be  distributed  to  all  of  the  name 
servers.  While  this  distribution  can  be  accomplished  using  FTP  or  some 
other  ad  hoc  procedure,  the  preferred  method  is  the  zone  transfer  part 
of  the  DNS  protocol. 

The  general  model  of  automatic  zone  transfer  or  refreshing  is  that  one 
of  the  name  servers  is  the  master  or  primary  for  the  zone.  Changes  are 
coordinated  at  the  primary,  typically  by  editing  a  master  file  for  the 
zone.  After  editing,  the  administrator  signals  the  master  server  to 
load  the  new  zone.  The  other  non-master  or  secondary  servers  for  the 
zone  periodically  check  for  changes  (at  a  selectable  interval)  and 
obtain  new  zone  copies  when  changes  have  been  made. 

To  detect  changes,  secondaries  just  check  the  SERIAL  field  of  the  SOA 
for  the  zone.  In  addition  to  whatever  other  changes  are  made,  the 
SERIAL  field  in  the  SOA  of  the  zone  is  always  advanced  whenever  any 
change  is  made  to  the  zone.  The  advancing  can  be  a  simple  increment,  or 
could  be  based  on  the  write  date  and  time  of  the  master  file,  etc.  The 
purpose  is  to  make  it  possible  to  determine  which  of  two  copies  of  a 
zone  is  more  recent  by  comparing  serial  numbers .  Serial  number  advances 
and  comparisons  use  sequence  space  arithmetic,  so  there  is  a  theoretic 
limit  on  how  fast  a  zone  can  be  updated,  basically  that  old  copies  must 
die  out  before  the  serial  number  covers  half  of  its  32  bit  range.  In 
practice,  the  only  concern  is  that  the  compare  operation  deals  properly 
with  comparisons  around  the  boundary  between  the  most  positive  and  most 
negative  32  bit  numbers. 

The  periodic  polling  of  the  secondary  servers  is  controlled  by 
parameters  in  the  SOA  RR  for  the  zone,  which  set  the  minimum  acceptable 
polling  intervals.  The  parameters  are  called  REFRESH,  RETRY,  and 
EXPIRE.  Whenever  a  new  zone  is  loaded  in  a  secondary,  the  secondary 
waits  REFRESH  seconds  before  checking  with  the  primary  for  a  new  serial. 
If  this  check  cannot  be  completed,  new  checks  are  started  every  RETRY 
seconds.  Tne  check  is  a  simple  query  to  the  primary  for  the  SOA  RR  of 
the  zone.  If  the  serial  field  in  the  secondary's  zone  copy  is  equal  to 
the  serial  returned  by  the  primary,  then  no  changes  have  occurred,  and 
the  REFRESH  interval  wait  is  restarted.  If  the  secondary  finds  it 
impossible  to  perform  a  serial  check  for  the  EXPIRE  interval,  it  must 
assume  that  its  copy  of  the  zone  is  obsolete  an  discard  it. 

When  the  poll  shows  that  the  zone  has  changed,  then  the  secondary  server 
must  request  a  zone  transfer  via  an  AXFR  request  for  the  zone.  The  AXFR 
may  cause  an  error,  such  as  refused,  but  normally  is  answered  by  a 
sequence  of  response  messages.  The  first  and  last  messages  must  contain 
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the  data  for  the  top  authoritative  node  of  the  zone.  Intermediate 
messages  carry  all  of  the  other  RRs  from  the  zone,  including  both 
authoritative  and  non-authoritative  Rils .  The  stream  of  messages  allows 
the  secondary  to  construct  a  copy  of  the  zone.  Because  accuracy  is 
essential,  TCP  or  some  other  reliable  protocol  must  be  used  for  AXFR 
requests . 

Each  secondary  server  is  required  to  perform  the  following  operations 
against  the  master,  but  may  also  optionally  perform  these  operations 
against  other  secondary  servers.  This  strategy  can  improve  the  transfer 
process  when  the  primary  is  unavailable  due  to  host  downtime  or  network 
problems,  or  when  a  secondary  server  has  better  network  access  to  an 
"intermediate"  secondary  than  to  the  primary. 

5 .  RESOLVERS 

5.1.  Introduction 

Resolvers  are  programs  that  interface  user  programs  to  domain  name 
servers.  In  the  simplest  case,  a  resolver  receives  a  request  from  a 
user  program  (e.g.,  mail  programs,  TELNET,  FTP)  in  the  form  of  a 
subroutine  call,  system  call  etc.,  and  returns  the  desired  information 
in  a  form  compatible  with  the  local  host's  data  formats. 

The  resolver  is  located  on  the  same  machine  as  the  program  that  requests 
the  resolver's  services,  but  it  may  need  to  consult  name  servers  on 
other  hosts.  Because  a  resolver  may  need  to  consult  several  name 
servers,  or  may  have  the  requested  information  in  a  local  cache,  the 
amount  of  time  that  a  resolver  will  take  to  complete  can  vary  quite  a 
bit,  from  milliseconds  to  several  seconds. 

A  very  important  goal  of  the  resolver  is  to  eliminate  network  delay  and 
name  server  load  from  most  requests  by  answering  them  from  its  cache  of 
prior  results.  It  follows  that  caches  which  are  shared  by  multiple 
processes,  users,  machines,  etc.,  are  more  efficient  than  non-shared 
caches . 

5.2.  Client-resolver  interface 
5.2.1.  Typical  functions 

The  client  interface  to  the  resolver  is  influenced  by  the  local  host's 
conventions,  but  the  typical  resolver-client  interface  has  three 
functions : 

1.  Host  name  to  host  address  translation. 

This  function  is  often  defined  to  mimic  a  previous  HOSTS.TXT 
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based  function.  Given  a  character  string,  the  caller  wants 
one  or  more  32  bit  IP  addresses.  Under  the  DNS,  it 
translates  into  a  request  for  type  A  RRs .  Since  the  DNS  does 
not  preserve  the  order  of  RRs,  this  function  may  choose  to 
sort  the  returned  addresses  or  select  the  "best"  address  if 
the  service  returns  only  one  choice  to  the  client .  Note  that 
a  multiple  address  return  is  recommended,  but  a  single 
address  may  be  the  only  way  to  emulate  prior  HOSTS.TXT 
services  . 

2.  Host  address  to  host  name  translation 

This  function  will  often  follow  the  form  of  previous 
functions.  Given  a  32  bit  IP  address,  the  caller  wants  a 
character  string.  The  octets  of  the  IP  address  are  reversed, 
used  as  name  components,  and  suffixed  with  "IN-ADDR.ARPA" .  A 
type  PTR  query  is  used  to  get  the  RR  with  the  primary  name  of 
the  host.  For  example,  a  request  for  the  host  name 
corresponding  to  IP  address  1.2. 3. 4  looks  for  PTR  RRs  for 
domain  name  "4 . 3 . 2 . 1 . IN-ADDR.ARPA" . 

3.  General  lookup  function 

This  function  retrieves  arbitrary  information  from  the  DNS, 
and  has  no  counterpart  in  previous  systems.  The  caller 
supplies  a  QNAME,  QTYPE,  and  QCLASS,  and  wants  all  of  the 
matching  RRs.  This  function  will  often  use  the  DNS  format 
for  all  RR  data  instead  of  the  local  host's,  and  returns  all 
RR  content  (e.g.,  TTL)  instead  of  a  processed  form  with  local 
quoting  conventions. 

When  the  resolver  performs  the  indicated  function,  it  usually  has  one  of 
the  following  results  to  pass  back  to  the  client: 

-  One  or  more  RRs  giving  the  requested  data. 

In  this  case  the  resolver  returns  the  answer  in  the 
appropriate  format. 

-  A  name  error  (NE) . 

This  happens  when  the  referenced  name  does  not  exist.  For 
example,  a  user  may  have  mistyped  a  host  name. 

-  A  data  not  found  error. 

This  happens  when  the  referenced  name  exists,  but  data  of  the 
appropriate  type  does  not .  For  example,  a  host  address 
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function  applied  to  a  mailbox  name  would  return  this  error 
since  the  name  exists,  but  no  address  RR  is  present. 

It  is  important  to  note  that  the  functions  for  translating  between  host 
names  and  addresses  may  combine  the  "name  error"  and  "data  not  found" 
error  conditions  into  a  single  type  of  error  return,  but  the  general 
function  should  not.  One  reason  for  this  is  that  applications  may  ask 
first  for  one  type  of  information  about  a  name  followed  by  a  second 
request  to  the  same  name  for  some  other  type  of  information;  if  the  two 
errors  are  combined,  then  useless  queries  may  slow  the  application. 

5.2.2.  Aliases 

While  attempting  to  resolve  a  particular  request,  the  resolver  may  find 
that  the  name  in  question  is  an  alias.  For  example,  the  resolver  might 
find  that  the  name  given  for  host  name  to  address  translation  is  an 
alias  when  it  finds  the  CNAME  RR.  If  possible,  the  alias  condition 
should  be  signalled  back  from  the  resolver  to  the  client. 

In  most  cases  a  resolver  simply  restarts  the  query  at  the  new  name  when 
it  encounters  a  CNAME.  However,  when  performing  the  general  function, 
the  resolver  should  not  pursue  aliases  when  the  CNAME  RR  matches  the 
query  type.  This  allows  queries  which  ask  whether  an  alias  is  present. 
For  example,  if  the  query  type  is  CNAME,  the  user  is  interested  in  the 
CNAME  RR  itself,  and  not  the  RRs  at  the  name  it  points  to. 

Several  special  conditions  can  occur  with  aliases.  Multiple  levels  of 
aliases  should  be  avoided  due  to  their  lack  of  efficiency,  but  should 
not  be  signalled  as  an  error.  Alias  loops  and  aliases  which  point  to 
non-existent  names  should  be  caught  and  an  error  condition  passed  back 
to  the  client. 

5.2.3.  Temporary  failures 

In  a  less  than  perfect  world,  all  resolvers  will  occasionally  be  unable 
to  resolve  a  particular  request.  This  condition  can  be  caused  by  a 
resolver  which  becomes  separated  from  the  rest  of  the  network  due  to  a 
link  failure  or  gateway  problem,  or  less  often  by  coincident  failure  or 
unavailability  of  all  servers  for  a  particular  domain. 

It  is  essential  that  this  sort  of  condition  should  not  be  signalled  as  a 
name  or  data  not  present  error  to  applications.  This  sort  of  behavior 
is  annoying  to  humans,  and  can  wreak  havoc  when  mail  systems  use  the 
DNS  . 

While  in  some  cases  it  is  possible  to  deal  with  such  a  temporary  problem 
by  blocking  the  request  indefinitely,  this  is  usually  not  a  good  choice, 
particularly  when  the  client  is  a  server  process  that  could  move  on  to 
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other  tasks.  The  recommended  solution  is  to  always  have  temporary 
failure  as  one  of  the  possible  results  of  a  resolver  function,  even 
though  this  may  make  emulation  of  existing  HOSTS.TXT  functions  more 
dif  f icult . 

5.3.  Resolver  internals 

Every  resolver  implementation  uses  slightly  different  algorithms,  and 
typically  spends  much  more  logic  dealing  with  errors  of  various  sorts 
than  typical  occurances .  This  section  outlines  a  recommended  basic 
strategy  for  resolver  operation,  but  leaves  details  to  [RFC-1035] . 

5.3.1.  Stub  resolvers 

One  option  for  implementing  a  resolver  is  to  move  the  resolution 
function  out  of  the  local  machine  and  into  a  name  server  which  supports 
recursive  queries.  This  can  provide  an  easy  method  of  providing  dom.ain 
service  in  a  PC  which  lacks  the  resources  to  perform  the  resolver 
function,  or  can  centralize  the  cache  for  a  whole  local  network  or 
organization . 

All  that  the  remaining  stub  needs  is  a  list  of  name  server  addresses 
that  will  perform  the  recursive  requests.  This  type  of  resolver 
presumably  needs  the  information  in  a  configuration  file,  since  it 
probably  lacks  the  sophistication  to  locate  it  in  the  domain  database. 
The  user  also  needs  to  verify  that  the  listed  servers  will  perform  the 
recursive  service;  a  name  server  is  free  to  refuse  to  perform  recursive 
services  for  any  or  all  clients.  The  user  should  consult  the  local 
system  administrator  to  find  name  servers  willing  to  perform  the 
service . 

This  type  of  service  suffers  from  some  drawbacks.  Since  the  recursive 
requests  may  take  an  arbitrary  amount  of  time  to  perform,  the  stub  may 
have  difficulty  optimizing  retransmission  intervals  to  deal  with  both 
lost  UDP  packets  and  dead  servers;  the  name  server  can  be  easily 
overloaded  by  too  zealous  a  stub  if  it  interprets  retransmissions  as  new 
requests.  Use  of  TCP  may  be  an  answer,  but  TCP  may  well  place  burdens 
on  the  host's  capabilities  which  are  similar  to  those  of  a  real 
resolver . 

5.3.2.  Resources 

In  addition  to  its  own  resources,  the  resolver  may  also  have  shared 
access  to  zones  maintained  by  a  local  name  server.  This  gives  the 
resolver  the  advantage  of  more  rapid  access,  but  the  resolver  must  be 
careful  to  never  let  cached  information  override  zone  data.  In  this 
discussion  the  term  "local  information"  is  meant  to  mean  the  union  of 
the  cache  and  such  shared  zones,  with  the  understanding  that 
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authoritative  data  is  always  used  in  preference  to  cached  data  when  both 
are  present . 

The  following  resolver  algorithm  assumes  that  all  functions  have  been 
converted  to  a  general  lookup  function,  and  uses  the  following  data 
structures  to  represent  the  state  of  a  request  in  progress  in  the 
resolver : 

SNAME  the  domain  name  we  are  searching  for. 

STYPE  the  QTYPE  of  the  search  request. 

SCLASS  the  QCLASS  of  the  search  request. 

SLIST  a  structure  which  describes  the  name  servers  and  the 

zone  which  the  resolver  is  currently  trying  to  query. 
This  structure  keeps  track  of  the  resolver's  current 
best  guess  about  which  name  servers  hold  the  desired 
information;  it  is  updated  when  arriving  information 
changes  the  guess.  This  structure  includes  the 
equivalent  of  a  zone  name,  the  known  name  servers  for 
the  zone,  the  known  addresses  for  the  name  servers,  and 
history  information  which  can  be  used  to  suggest  which 
server  is  likely  to  be  the  best  one  to  try  next.  The 
zone  name  equivalent  is  a  match  count  of  the  number  of 
labels  from  the  root  down  which  SNAME  has  in  common  with 
the  zone  being  queried;  this  is  used  as  a  measure  of  how 
"close"  the  resolver  is  to  SNAME. 

SBELT  a  "safety  belt"  structure  of  the  same  form  as  SLIST, 

which  is  initialized  from  a  configuration  file,  and 
lists  servers  which  should  be  used  when  the  resolver 
doesn't  have  any  local  information  to  guide  name  server 
selection.  The  match  count  will  be  -1  to  indicate  that 
no  labels  are  known  to  match. 

CACHE  A  structure  which  stores  the  results  from  previous 

responses.  Since  resolvers  are  responsible  for 
discarding  old  RRs  whose  TTL  has  expired,  most 
implementations  convert  the  interval  specified  in 
arriving  RRs  to  some  sort  of  absolute  time  when  the  RR 
is  stored  in  the  cache.  Instead  of  counting  the  TTLs 
down  individually,  the  resolver  just  ignores  or  discards 
old  RRs  when  it  runs  across  them  in  the  course  of  a 
search,  or  discards  them  during  periodic  sweeps  to 
reclaim  the  memory  consumed  by  old  RRs. 
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5.3.3.  Algorithm 

The  top  level  algorithm  has  four  steps; 

1 .  See  if  the  answer  is  in  local  information,  and  if  so  return 
it  to  the  client. 

2.  Find  the  best  servers  to  ask. 

3.  Send  them  queries  until  one  returns  a  response. 

4.  Analyze  the  response,  either: 

a.  if  the  response  answers  the  question  or  contains  a  name 
error,  cache  the  data  as  well  as  returning  it  back  to 
the  client . 

b.  if  the  response  contains  a  better  delegation  to  other 
servers,  cache  the  delegation  information,  and  go  to 
step  2 . 

C.  if  the  response  shows  a  CNAME  and  that  is  not  the 

answer  itself,  cache  the  CNAME,  change  the  SNAME  to  the 
canonical  name  in  the  CNAME  RR  and  go  to  step  1. 

d.  if  the  response  shows  a  servers  failure  or  other- 

bizarre  contents,  delete  the  server  from  the  SLIST  and 
go  back  to  step  3 . 

Step  1  searches  the  cache  for  the  desired  data.  If  the  data  is  in  the 
cache,  it  is  assumed  to  be  good  enough  for  normal  use.  Some  resolvers 
have  an  option  at  the  user  interface  which  will  force  the  resolver  to 
ignore  the  cached  data  and  consult  with  an  authoritative  server.  This 
is  not  recommended  as  the  default.  If  the  resolver  has  direct  access  to 
a  name  server's  zones,  it  should  check  to  see  if  the  desired  data  is 
present  in  authoritative  form,  and  if  so,  use  the  authoritative  data  in 
preference  to  cached  data. 

Step  2  looks  for  a  name  server  to  ask  for  the  required  data.  The 
general  strategy  is  to  look  for  locally-available  name  server  RRs, 
starting  at  SNAME,  then  the  parent  domain  name  of  SNAME,  the 
grandparent,  and  so  on  toward  the  root.  Thus  if  SNAME  were 
Mockapetris.ISI.EDU,  this  step  would  look  for  NS  RRs  for 
Mockapetris.ISI.EDU,  then  ISI.EDU,  then  EDU,  and  then  .  (the  root) . 

These  NS  RRs  list  the  names  of  hosts  for  a  zone  at  or  above  SNAME.  Copy 
the  names  into  SLIST.  Set  up  their  addresses  using  local  data.  It  may 
be  the  case  that  the  addresses  are  not  available.  The  resolver  has  many 
choices  here;  the  best  is  to  start  parallel  resolver  processes  looking 


Mockapetris 


[Page  34] 


4-44 


Domain  Names  -  Concepts  and  Facilities 


RFC  1034 


RFC  1034  Domain  Concepts  and  Facilities  November  1967 


for  the  addresses  while  continuing  onward  with  the  addresses  which  are 
available.  Obviously,  the  design  choices  and  options  are  complicated 
and  a  function  of  the  local  host's  capabilities.  The  recommended 
priorities  for  the  resolver  designer  are: 

1.  Bound  the  amount  of  work  (packets  sent,  parallel  processes 
started)  so  that  a  request  can't  get  into  an  infinite  loop  or 
start  off  a  chain  reaction  of  requests  or  queries  with  other 
implementations  EVEN  IF  SOMEONE  HAS  INCORRECTLY  CONFIGURED 
SOME  DATA. 

2.  Get  back  an  answer  if  at  all  possible. 

3.  Avoid  unnecessary  transmissions. 

4.  Get  the  answer  as  quickly  as  possible. 

If  the  search  for  NS  RRs  fails,  then  the  resolver  initializes  SLIST  from 
the  safety  belt  SBELT .  The  basic  idea  is  that  when  the  resolver  has  no 
idea  what  servers  to  ask,  it  should  use  information  from  a  configuration 
file  that  lists  several  servers  which  are  expected  to  be  helpful. 
Although  there  are  special  situations,  the  usual  choice  is  two  of  the 
root  servers  and  two  of  the  servers  for  the  host's  domain.  The  reason 
for  two  of  each  is  for  redundancy.  The  root  servers  will  provide 
eventual  access  to  all  of  the  domain  space.  The  two  local  servers  will 
allow  the  resolver  to  continue  to  resolve  local  names  if  the  local 
network  becomes  isolated  from  the  internet  due  to  gateway  or  link 
failure . 

In  addition  to  the  names  and  addresses  of  the  servers,  the  SLIST  data 
structure  can  be  sorted  to  use  the  best  servers  first,  and  to  insure 
that  all  addresses  of  all  servers  are  used  in  a  round-robin  manner.  The 
sorting  can  be  a  simple  function  of  preferring  addresses  on  the  local 
network  over  others,  or  may  involve  statistics  from  past  events,  such  as 
previous  response  times  and  batting  averages. 

Step  3  sends  out  queries  until  a  response  is  received.  The  strategy  is 
to  cycle  around  all  of  the  addresses  for  all  of  the  servers  with  a 
timeout  between  each  transmission.  In  practice  it  is  important  to  use 
all  addresses  of  a  multihomed  host,  and  too  aggressive  a  retransmission 
policy  actually  slows  response  when  used  by  multiple  resolvers 
contending  for  the  same  name  server  and  even  occasionally  for  a  single 
resolver.  SLIST  typically  contains  data  values  to  control  the  timeouts 
and  keep  track  of  previous  t ransmissions . 

Step  4  involves  analyzing  responses.  The  resolver  should  be  highly 
paranoid  in  its  parsing  of  responses.  It  should  also  check  that  the 
response  matches  the  query  it  sent  using  the  ID  field  in  the  response. 
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The  ideal  answer  is  one  from  a  server  authoritative  for  the  query  which 
either  gives  the  required  data  or  a  name  error.  The  data  is  passed  back 
t j  the  user  and  entered  in  the  cache  for  future  use  if  its  TTL  is 
greater  than  zero. 

If  the  response  shows  a  delegation,  the  resolver  should  check  to  see 
that  the  delegation  is  "closer"  to  the  answer  than  the  servers  in  SLIST 
are.  This  can  be  done  by  co.mparxng  the  match  count  in  SLIST  with  that 
co.mputed  from  SNAME  and  the  NS  RRs  in  the  delegation.  If  not,  the  reply 
IS  bogus  and  should  be  ignored.  If  the  delegation  is  valid  the  NS 
delegatio.n  RRs  and  any  address  RRs  for  the  servers  should  be  cached. 

The  name  servers  are  entered  in  the  SLIST,  and  the  search  is  restarted. 

If  the  response  contains  a  CNAME,  the  search  is  restarted  at  the  CNAME 
u.nless  the  response  has  the  data  for  the  canonical  name  or  if  the  CNAME 
is  the  answer  itself. 

Details  and  implementation  hints  can  be  found  in  [RFC-1035]. 

6 .  A  SCENARIO 

In  our  sample  domain  space,  suppose  we  wanted  separate  adrrdnist rat ive 
control  for  the  root,  MIL,  EDU,  MIT.EDU  and  ISI.EDU  zones.  We  might 
allocate  name  servers  as  follows: 


I  (C. ISI.EDU, SRI-NIC.ARPA 
I  A. ISI.EDU) 


MIL 

I (SRI-NIC.ARPA, 
I  A. ISI.EDU 
+ - + - + 

I  I  I 

BRL  NOSC  DARPA 


EDU  ARPA 

I (SRI-NIC.ARPA,  I 

1  C. ISI.EDU)  I 

III  I 

I  IN-ADDR  SRI-NIC  ACC 


+ - + - - - 

II  I  II 

UCI  MIT  I  UDEL  YALE 

I {XX. LCS .MIT.EDU,  ISI 

IACHILLES.MIT.EDU)  | (VAXA . ISI . EDU, VENERA . ISI . EDU, 

+ - + - +  I  A. ISI.EDU) 

!  I  I 

LCS  ACHILLES  +  —  + - + - + - + 

I  I  I  I  I  I 

XX  AC  VAXA  VENERA  Mockapetris 
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Ir  this  example,  the  authoritative  name  server  is  shown  in  parentheses 
at  the  point  in  the  domain  tree  at  which  is  assumes  control. 

Thus  the  root  name  servers  are  on  C. ISI.EDU,  SRI-NIC . ARPA,  and 
A. ISI.EDU.  The  MIL  domain  is  served  by  SRI-NIC. ARPA  and  A. ISI.EDU.  The 
EDU  dom.arn  is  served  by  SRT-NIC .  ARPA.  and  C.  ISI.EDU.  Note  that  servers 
may  have  zones  which  are  contiguous  or  disjoint.  In  this  scenario, 

C. ISI.EDU  has  contiguous  zones  at  the  root  and  EDU  domains.  A. ISI.EDU 
has  contiguous  zones  at  the  root  and  MIL  domains,  but  also  has  a  non¬ 
contiguous  zone  at  ISI.EDU. 

6.1.  C. I  SI. EDU  name  server 

C. ISI.EDU  is  a  name  server  for  the  root,  MIL,  and  EDU  domains  of  the  IN 
class,  and  would  have  zones  for  these  dom.ains.  The  zone  data  for  the 
rest  domain  might  be: 

IN  SOA  SRI-NIC. ARPA 

870611 
180C 
300 

604800 
86400) 

NS  A. ISI.EDU. 

NS  C. I SI. EDU. 

NS  SRI-NIC. ARPA 

MIL.  86400  NS  SRI -NIC . ARPA . 

86400  NS  A. ISI.EDU. 

EDU.  86400  NS  SRI-NIC . ARPA . 

86400  NS  C. ISI.EDU. 

SRI-NIC .ARPA.  A  26.0.0.73 

A  10.0.0.51 

MX  0  SRI-NIC. ARPA. 

HINFO  DEC-2060  TOPS20 

ACC. ARPA.  A  26.6.0.65 

HINFO  PDP-11/70  UNIX 

MX  10  ACC . ARPA . 

USC-ISIC . ARPA.  CNAME  C. ISI.EDU. 

73 . 0 . 0 . 26 . IN-ADDR. ARPA.  PTR  SRI -NIC . ARPA . 

65 . 0 . 6 .26 . IN-ADDR.ARFA.  FTR  ACC . ARPA . 

51 . 0 . 0 . 10 . IN-ADDR. ARPA.  PTR  SRI -NIC . ARPA . 

52  . 0  .  0  .  10  .  IN-ADDR. ARPA.  PTR  C. ISI.EDU. 


•Mock-apetris 


.  HOSTMASTER. SRI -NIC .ARPA.  { 
/serial 

/refresh  every  30  min 
/retry  every  5  min 
/expire  after  a  week 
/minimum  of  a  day 
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IC'3 . 0  .  3 . 26  .  IN-ADDR.  ARPA.  PTR  A.  ISI.EDU. 

A.rsi.ED'J.  8  640  0  A  2  6  3.C.103 

C.ISI.EDU.  86400  A  10.0.0.52 

This  data  is  represented  as  it  would  be  in  a  master  file.  Most  RRs  are 
sir.  ;;le  li.ne  entries;  the  sole  exception  here  is  the  SOA  RR,  which  uses 
" (  "  to  start  a  multi-line  RR  and  " ) "  to  show  the  end  of  a  multi-line  RR. 
S;r, oe  the  class  of  all  RRs  in  a  zone  must  oe  the  same,  only  the  first  RR 
a  zc.ne  .need  specify  the  class.  When  a  name  server  loads  a  zone,  it 
:  :  ;  tes  the  TTL  of  all  authoritative  RRs  to  be  at  least  the  MINIMUM  field 
:r  the  3C.A,  here  86400  seconds,  or  one  day.  The  NS  RRs  marking 
d'.;  legat  icr.  of  the  MIL  and  EDU  domains,  together  with,  the  glue  RRs  for 
t;.e  servers  host  addresses,  are  net  part  of  the  authoritative  data  in 
t  :.e  zone,  and  hence  have  explicit  TTLs . 

r'tur  RRs  are  attached  to  the  root  node:  the  SOA  which  describes  the  root 
ztne  and  the  3  NS  RRs  which  list  the  name  servers  for  the  root.  The 
data  in  the  SOA  RR  describes  the  management  of  the  zone.  The  zone  data 
IS  rr.aintalned  on  host  SRI -NIC .  ARPA,  and  the  responsible  party  for  the 
zone  is  HCSTMA3TER@ SRI-NIC . ARPA .  A  key  item  in  the  SOA  is  the  86400 
second  minimum  TTL,  which  means  that  all  authoritative  data  in  the  zone 
has  at  least  that  TTL,  although  higher  values  may  be  explicitly 
specif ied . 

The  NS  R.Rs  for  the  MIL  and  EDU  domains  mark  the  boundary  between  the 
root  zone  and  the  MIL  and  EDU  zones.  Note  that  in  this  example,  the 
lower  zones  happen  to  be  supported  by  name  servers  which  also  support 
the  root  zone. 

The  master  file  for  the  EDU  zone  might  be  stated  relative  to  the  origin 
EDU.  The  zone  data  for  the  EDU  domain  might  be: 

EDU.  IN  SOA  SRI-NIC. ARPA.  HOSTMASTER . SRI -NIC . ARP A .  ( 

870729  /serial 

1800  /refresh  every  30  minutes 
300  /retry  every  5  minutes 
604800  /expire  after  a  week 
86400  /minimum  of  a  day 
) 

NS  SRI-NIC .ARPA. 

NS  C. ISI.EDU. 

uc:  172800  NS  ICS.UCI 

172800  NS  ROME.UCI 
ICS.UCI  172800  A  192.5.19.1 
POME.UCI  172800  A  192.5.19.31 
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ISI  172800  NS  VAXA.ISI 

172800  NS  A. ISI 

172800  NS  VENERA.ISI.EDU. 

VAXA.ISI  172800  A  10.2.0.27 

172800  A  128.9.0.33 
VENERA.ISI.EDU.  172800  A  10.1.0.52 
172800  A  128.9.0.32 
A. ISI  172800  A  26.3.0.103 

UDEL.EDU.  172800  NS  LOUIE.UDEL.EDU. 

172800  NS  UMN-REI-UC .ARPA. 

LOUIE.UDEL.EDU.  172800  A  10.0.0.96 
172800  A  192.5.39.3 

YALE.EDU.  172800  NS  YALE. ARPA. 

YALE.EDU.  172800  NS  YALE -BULLDOG . ARPA . 

MIT.EDU.  43200  NS  XX.LCS.MIT.EDU. 

43200  NS  ACHILLES.MIT.EDU. 

XX.LCS.MIT.EDU.  43200  A  10.0.0.44 
ACHILLES.MIT.EDU.  43200  A  18.72.0.8 

Note  the  use  of  relative  names  here.  The  owner  name  for  the  ISI.EDU.  is 
stated  using  a  relative  name,  as  are  two  of  the  name  server  RR  contents. 
Relative  and  absolute  domain  names  may  be  freely  intermixed  in  a  master 

6.2.  Example  standard  queries 

The  following  queries  and  responses  illustrate  name  server  behavior. 
Unless  otherwise  noted,  the  queries  do  not  have  recursion  desired  (RD) 
in  the  header.  Note  that  the  answers  to  non-recursive  queries  do  depend 
on  the  server  being  asked,  but  do  not  depend  on  the  identity  of  the 
requester . 
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6.2.1.  QNAME=SRr-NIC.ARPA,  QTYPE=A 
Tr.e  query  would  look  like: 


Header 

Question 

Answer 

Authority 

Additional 


+ - 4- 

I  OPCODE=SQUERY  I 

+ - + 

I  QNAME=SRI-NIC .ARPA. ,  QCLASS=IN,  QTYPE=A  I 

4. - 4. 

I  <empty>  I 

4- - + 

1  <empty>  I 

+ - 4- 

1  <empty>  I 

4. - 4- 


The  response  from  C. ISI.EDU  would  be: 


4- 


Header 

Question 

Answer 


I  OPCODE=SQUERY,  RESPONSE,  AA 

4- - 

I  QNAME=SRI-NIC . ARPA. ,  QCLASS=IN,  QTYPE=A 
4- - 

I  SRI-NIC . ARPA.  86400  IN  A  26.0.0.73 
I  86400  IN  A  10.0.0.51 

4. - 


Authority  |  <empty> 

4. - 

Additional  1  <empty> 

4. - 


4- 

I 

4- 

I 

4- 


4- 

I 

4- 

I 

4- 


The  header  of  the  response  looks  like  the  header  of  the  query,  except 
that  the  RESPONSE  bit  is  set,  indicating  that  this  message  is  a 
response,  not  a  query,  and  the  Authoritative  Answer  (AA)  bit  is  set 
indicating  that  the  address  RRs  in  the  answer  section  are  from 
authoritative  data.  The  question  section  of  the  response  matches  the 
question  section  of  the  query. 
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If  the  same  query  was  sent  to  some  other  server  which  was  not 
authoritative  for  SRI-NIC . ARPA,  the  response  might  be: 

+ - 


Header 

Question 

Answer 

Authority 

Additional 


I  OPCODE=SQUERY, RESPONSE 

+ - 

1  QNAME=SRI -NIC .ARPA. ,  QCLASS=IN,  QTYPE=A 

+ - 

I  SRI-NIC .ARPA.  1777  IN  A  10.0.0.51 
I  1777  IN  A  26.0.0.73 

+ - 

1  <empty> 

+ - 

I  <empty> 

H - 


+ 

I 

+ 

I 

+ 


+ 

I 

+ 

I 

+ 


This  response  is  different  from  the  previous  one  in  two  ways:  the  header 
does  not  have  AA  set,  and  the  TTLs  are  different.  The  inference  is  that 
the  data  did  not  come  from  a  zone,  but  from  a  cache.  The  difference 
between  the  authoritative  TTL  and  the  TTL  here  is  due  to  aging  of  the 
data  in  a  cache.  The  difference  in  ordering  of  the  RRs  in  the  answer 
section  is  not  significant. 


6.2.2.  QNAME=SRI-NIC.ARPA,  QTYPE=* 


A  query  similar  to  the  previous  one,  but  using  a  QTYPE  of  *,  would 
receive  the  following  response  from  C. ISI.EDU: 


Hs3d.o  r 

Question 

Answer 


Authority 
Addit ional 


- + 

I  CPCCDE-SQUERY,  RESPONSE,  AA  i 

+ - + 

1  QNAME=SRI-NIC .  A.RPA.  ,  QCLASS  =  IN,  QTYPE=*  1 

+ - + 

I  SRI-NIC .ARPA.  86400  IN  A  26.0.0.73  I 

I  A  10.0.0.51  I 

I  MX  0  SRI-NIC .ARPA.  | 

I  HINFO  DEC-2060  TOPS20  I 

+ - + 

I  <empty>  I 

+ - + 

I  <empty>  I 

+ - + 
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If  a  similar  query  was  directed  to  two  name  servers  which  are  not 
authoritative  for  SRI-NIC . ARPA,  the  responses  might  be: 


Header 

Question 

Answer 

Authority 

Additional 


OPCODE=SQUERY,  RESPONSE 

QN>iME=SRI-NIC.ARPA.  ,  QCLASS  =  IN, 

QTYPE=* 

SRI-NIC. ARPA.  12345  IN  A 

26.0.0.73 

A 

10.0.0.51 

<empty> 

<empty> 

+ 

I 

+ 

I 

+ 


+ 

I 

+ 

I 

■f 


and 


Header 

Question 

Answer 

Authority 

Additional 


+ - 

I  OPCODE=SQUERY,  RESPONSE 

+ - 

I  QNAME=SRI -NIC. ARPA. ,  QCLASS=IN,  QTYPE=* 

+ - 

I  SRI-NIC. ARPA.  1290  IN  HINFO  DEC-2060  TOPS20 

+ - 

I  <empty> 

+ - 

I  <empty> 

+ - 


+ 

1 

+ 

I 

+ 

I 

+ 

I 

+ 

i 

■  + 


Neither  of  these  answers  have  AA  set,  so  neither  response  comes  from 
authoritative  data.  The  different  contents  and  different  TTLs  suggest 
that  the  two  servers  cached  data  at  different  times,  and  that  the  first 
server  cached  the  response  to  a  QTYPE=A  query  and  the  second  cached  the 
response  to  a  HINFO  query. 
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6.2.3.  QNAME=SRI-NIC.ARPA,  QTYPE=MX 


This  type  of  query  might  be  result  from  a  mailer  trying  to  look  up 
routing  information  for  the  mail  destination  HOSTMASTER@SRI-NIC.ARPA. 
The  response  from  C. ISI.EDU  would  be: 


Header 

Question 

Answer 

Authority 

Additional 


OPCODE=SQUERY, 

RESPONSE, 

AA 

QNAME=SRI-NIC. 

ARPA.,  QCLASS=IN, 

QTYPE=MX 

SRI-NIC . ARPA. 

86400  IN 

MX 

0  SRI-NIC. ARPA. 

kempty> 

SRI-NIC .ARPA. 

86400  IN 

A 

26.0.0.73 

A 

10.0.0.51 

This  response  contains  the  MX  RR  in  the  answer  section  of  the  response. 
The  additional  section  contains  the  address  RRs  because  the  name  server 
at  C. ISI.EDU  guesses  that  the  requester  will  need  the  addresses  in  order 
to  properly  use  the  information  carried  by  the  MX. 

6.2.4.  QNAME=SRI-NIC . ARPA,  QTYPE=NS 

C. ISI.EDU  would  reply  to  this  query  with: 


Header 

Question 

Answer 

Authority 

Additional 


4 - 4 

I  OPCODE=SQUERY,  RESPONSE,  AA  1 

4 - 4 

I  QNAME=SRI-NIC.ARPA. ,  QCLASS=IN,  QTYPE=NS  i 

4 - 4 

I  kempt y>  I 

4 - 4 

I  kempt y>  I 

4 - 4 

I  kempty>  I 

4 - 4 


The  only  difference  between  the  response  and  the  query  is  the  AA  and 
RESPONSE  bits  in  cue  neader.  The  interpretation  of  this  response  is 
that  the  server  is  authoritative  for  the  name,  and  the  name  exists,  but 
no  RRs  of  type  NS  are  present  there. 

6.2.5.  QN.AME=SIR-NIC.ARPA,  QTYPE=A 

If  a  user  mistyped  a  host  name,  we  might  see  this  type  of  query. 
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C. ISI.EDU  would  answer  it  with: 


Header 

Question 

Answer 

Authority 

Additional 


+ - 

1  OPCODE=SQUERY,  RESPONSE,  AA,  RCODE=NE 

+ - 

I  QNAME=SIR-NIC.ARPA. ,  QCLASS=IN,  QTyPE=A 

+ - 

I  <6mpty> 

+ - 

1  .  SOA  SRI-NIC.ARPA.  HOSTMASTER . SRI-NIC . ARPA . 

!  870611  1800  300  604800  86400 

+ - 

I  <empty> 

+ - 


+ 

I 

+ 

I 

+ 

I 

+ 


+ 

I 

+ 


This  response  states  that  the  name  does  not  exist.  This  condition  is 
signalled  in  the  response  code  (RCODE)  section  of  the  header. 

The  SOA  RR  in  the  aut.hority  section  is  the  optional  negative  caching 
information  which  allows  the  resolver  using  this  response  to  assume  that 
the  name  will  not  exist  for  the  SOA  MINIMUM  (86400)  seconds. 

6.2.6.  QNAME=BRL.MIL,  QTYPE=A 

If  this  query  is  sent  to  C. ISI.EDU,  the  reply  would  be: 


Header 

Question 

1  OPCODE=SQUERY, 

1  QNAME=BRL.MIL, 

RESPONSE 

QCLASS=IN, 

QTYPE=A 

Answer 

i  <empty> 

Authority 

1  MIL. 

86400  IN 

NS  SRI-NIC.ARPA. 

1 

86400 

NS  A. ISI.EDU. 

Additional 

1  A. ISI.EDU. 

A  26.3.0.103 

1  SRI-NIC.ARPA. 

A  26.0.0.73 

1 

+ - 

A  10.0.0.51 

This  response  has  an  empty  answer  section,  but  is  not  authoritative,  so 
it  is  a  referral.  The  name  server  on  C. ISI.EDU,  realizing  that  it  is 
not  authoritative  for  the  MIL  domain,  has  referred  the  requester  to 
servers  on  A.  ISI.EDU  and  SRI-NIC.ARPA,  which  it  Icnows  are  authoritative 
for  the  MIL  domain. 
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response  to 

this  query  from 

A. ISI.EDU  would  be 

Header 

1  OPCODE=SQUERY, 

RESPONSE,  AA 

Question 

1  QNAME=USC-ISIC, 

,ARPA.,  QCLASS=IN, 

QTYPE=A 

Answer 

1  USC-ISIC .ARPA. 

86400  IN  CNAME 

C. ISI  . 

EDU. 

1  C. ISI.EDU. 

86400  IN  A 

10.0.0 

.52 

Authority 

1  <empty> 

Additional 

1  <empty> 

Note  that  the  AA  bit  in  the  header  guarantees  that  the  data  matching 
QNAME  is  authoritative,  but  does  not  say  anything  about  whether  the  data 
for  C. IS1.EDU  is  authoritative.  This  complete  reply  is  possible  because 
A. ISI.EDU  happens  to  be  authoritative  for  both  the  ARPA  domain  where 
USC-ISIC . ARPA  is  found  and  the  ISI.EDU  domain  where  C. ISI.EDU  data  is 
found . 

If  the  same  query  was  sent  to  C. ISI.EDU,  its  response  might  be  the  same 
as  shown  above  if  it  had  its  own  address  in  its  cache,  but  might  al.so 
be : 
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.Header 

+  - 

1 

OPCODE=SQUERY, 

RESPONSE 

,  AA 

Question 

1 

QNAME=USC-ISIC. 

.ARPA.,  QCLASS=IN, 

QTYPE=A 

An  3  we  r 

1 

USC-ISIC. ARPA. 

86400 

IN  CNA.ME 

C.  ISI .EDU. 

Authority 

! 

ISI.EDU. 

172800 

IN  NS 

VAXA.ISI.EDU . 

1 

NS 

A.  ISI .EDU. 

1 

NS 

VENERA. ISI .EDU. 

Additional 

VAXA. ISI.EDU. 

172800 

A 

10.2.0.27 

1 

172800 

A 

128.9.0.33 

1 

VENERA. IS  I .EDU, 

.  172800 

A 

10.1.0.52 

1 

172800 

A 

128.9.0.32 

1 

+  - 

A.  ISI .EDU. 

172800 

A 

26.3.0.103 

This  reply  contains  an  authoritative  reply  for  the  alias  USC-ISIC . ARPA, 
plus  a  referral  to  the  name  servers  for  ISI.EDU.  This  sort  of  reply 
isn't  very  likely  given  that  the  query  is  for  the  host  name  of  the  name 
server  being  asked,  but  would  be  common  for  other  aliases. 

6.2.8.  QNAME=USC-ISIC .ARPA,  QTYPE=CNAME 

If  this  query  is  sent  to  either  A. ISI.EDU  or  C. ISI.EDU,  the  reply  would 
be : 


Header 

1  OPCODE=SQUERY,  RESPONSE,  AA 

Quest  ion 

1  QNAME=USC-ISIC.ARPA. ,  QCLASS=IN, 

QTYPE=A 

Answer 

1  USC-ISIC .ARPA.  86400  IN  CNAME 

C. ISI. EDU. 

Authority 

1  <empty> 

Additional 

1  <empty> 

+ - 

Because  QTYPE=CNAME,  the  CNAME  RR  itself  answers  the  query,  and  the  name 
server  doesn't  attempt  to  look  up  anything  for  C. ISI.EDU.  (Except 
possibly  for  the  additional  section.) 

6.3.  Example  resolution 

The  following  examples  illustrate  the  operations  a  resolver  must  perform 
for  its  client.  We  assume  that  the  resolver  is  starting  without  a 
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cache,  as  might  be  the  case  after  system  boot.  We  further  assume  that 
the  system  is  not  one  of  the  hosts  in  the  data  and  that  the  host  is 

located  somewhere  on  net  26,  and  that  its  safety  belt  (SBELT)  data 

structure  has  the  following  information: 

Match  count  =  -1 

SRI-NIC . ARPA.  26.0.0.73  10.0.0.51 

A. I SI.EDU.  26.3.0.103 

This  information  specifies  servers  to  try,  their  addresses,  and  a  match 
count  of  -1,  which  says  that  the  servers  aren't  very  close  to  the 
target.  Note  that  the  -1  isn't  supposed  to  be  an  accurate  closeness 
measure,  just  a  value  so  that  later  stages  of  the  algorithm  will  work.. 

The  following  examples  illustrate  the  use  of  a  cache,  so  each  example 
assumes  that  previous  requests  have  completed. 

6.3.1.  Resolve  MX  for  ISI.EDU. 

Suppose  the  first  request  to  the  resolver  comes  from  the  local  mailer, 
which  has  mail  for  PVM0ISI.EDU.  The  mailer  might  then  ask  for  type  MX 
RRs  for  the  domain  name  ISI.EDU. 

The  resolver  would  look  in  its  cache  for  MX  RRs  at  ISI.EDU,  but  the 
empty  cache  wouldn't  be  helpfu.. .  The  resolver  would  recognize  that  it 
needed  to  query  foreign  servers  and  try  to  determine  the  be.st  servers  to 
query.  This  search  would  look  for  NS  RRs  for  the  domains  ISI.EDU,  EDU, 
and  the  root.  These  searches  of  the  cache  would  also  fail.  As  a  last 
resort,  the  resolver  would  use  the  information  from  the  SBELT,  copying 
it  into  its  SLIST  structure. 

At  this  point  the  resolver  would  need  to  pick  one  of  the  three  available 
addresses  to  try.  Given  that  the  resolver  is  on  net  26,  it  should 
choose  either  26.0.0.73  or  26.3.0.103  as  its  first  choice.  It  would 
then  send  off  a  query  of  the  form: 
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Heade  r 
Quest  ion 
An  s  we  r 
Authority 
Additional 


I  OPCODE=SQUERy 

+ - 

QNAME=ISI .EDU. ,  QCLASS=IN,  QTYPE=MX 

+ - 

I  <empty> 

+ - 

I  <empty> 


1  <empty> 
+ - 


■  + 
I 

+ 

I 

+ 

I 

+ 

I 

+ 

1 

+ 


Tiie  resolver  would  then  wait  for  a  response  to  its  query  or  a  timeout. 
If  the  timeout  occurs,  it  would  try  different  servers,  then  different 
addresses  of  the  same  servers,  lastly  retrying  addresses  already  tried. 
It  might  eventually  receive  a  reply  from  SRI-NIC . ARPA r 


Header 

1  OPCODE=SQUERY, 

RESPONSE 

Question 

1  QNAME=ISI .EDU. , 

QCLASS=IN, 

QTYPE 

=MX 

Answer 

1  <empty> 

Authority 

1  ISI.EDU. 

172800  IN 

NS 

VAXA.ISI.EDU . 

1 

NS 

A. ISI .EDU. 

1 

NS 

VENERA.ISI.EDU. 

Addit ional 

1  VAXA.ISI.EDU. 

172800 

A 

10.2.0.27 

1 

172800 

A 

128.9.0.33 

1  VENERA.ISI.EDU, 

.  172800 

A 

10.1.0.52 

1 

172800 

A 

128.9.0.32 

t  A. ISI.EDU. 

172800 

A 

26.3.0.103 

The  resolver  would  notice  that  the  information  in  the  response  gave  a 
closer  delegation  to  ISI.EDU  than  its  existing  SLIST  (since  it  matches 
three  labels)  .  The  resolver  would  then  cache  the  information  in  this 
response  and  use  it  to  set  up  a  new  SLIST: 

Match  count  =  3 
A. Isr.EDU.  26.3.0.103 

VAXA.ISI.EDU.  10.2.0.27  128.9.0.33 

VENERA.ISI.EDU.  10.1.0.52  128.9.0.32 

A. I3I.EDU  appears  on  this  list  as  well  as  the  previous  one,  but  that  is 
purely  coincidental.  The  resolver  would  again  start  transmitting  and 
waiting  for  responses.  Eventually  it  would  get  an  answer: 
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Header 
Quest  ion 
Answe  r 


Authority 
Addit iona 1 


OPCODE=SQUERY, 

RESPONSE 

,  AA 

QNAME=ISI .EDU.  , 

QCLASS= 

IN, 

QTYPE=MX 

ISI .EDU. 

MX 

10  VENERA.ISI.EDU. 

MX 

20  VAXA.ISI.EDU. 

<empty> 

VAXA. ISI .EDU. 

172800 

A 

10.2.0.27 

172800 

A 

128.9.0.33 

VENERA. ISI .EDU. 

172800 

A 

10.1.0.52 

172800 

A 

128.9.0.32 

The  resolver  would  add  this  information  to  its  cache,  and  return  the  MX 
RRs  to  its  client. 

6.3.2.  Get  the  host  name  for  address  26.6.0.65 

The  resolver  would  translate  this  into  a  request  for  PTR  RRs  for 
6 5 . 0 . 6 . 2 6 . IN-ADDR . ARPA .  This  information  is  not  in  the  cache,  so  the 
resolver  would  look  for  foreign  servers  to  ask.  No  servers  would  match, 
so  it  would  use  SBELT  again.  (Note  that  the  servers  for  the  ISI.EDU 
domain  are  in  the  cache,  but  ISI.EDU  is  not  an  ancestor  of 
65 . 0 . 6 . 26 . IN-ADDR. ARPA,  so  the  SBELT  is  used.) 

Since  this  request  is  within  the  authoritative  data  of  both  servers  in 
SBELT,  eventually  one  would  return: 
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Heade: 


OPCODE=SQUERY,  RESPONSE,  AA 


pjest  ion 


Answer 


QNAME=65 .0.6.26. IN-ADDR . ARPA . , QCLASS=IN, QTYPE=PTR  I 


65  .  0  .  6 . 26  .  IN-ADDR..ARPA.  PTR 


ACC. ARPA. 


Authority  I  <empty> 


-Additional  j  <empty> 


6,3.3.  Get  the  host  address  of  poneria.ISI.EDU 

This  request  would  translate  into  a  type  A  request  for  poneria.ISI.EDU. 
The  resolver  would  not  find  any  cached  data  for  t.his  name,  but  would 
find  the  NS  RRs  in  the  cache  for  ISI.EDU  when  it  looks  for  foreign 
servers  to  ask.  Using  this  data,  it  would  construct  a  SLIST  of  the 


Match  count  =  3 

A. ISI.EDU.  26.3.0.103 

VAXA.ISI.EDU.  10.2.0.27 
VENERA.ISI.EDU.  10.1.0.52 


128.9.0.33 


A.  ISI.EDU  is  listed  first  on  the  assumption  that  the  resolver  orders  its 
choices  by  preference,  and  A. ISI.EDU  is  on  the  same  network. 

One  of  these  servers  would  answer  the  query. 
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DOMAIN  NAMES  -  IMPLEMENTATION  AND  SPECIFICATION 


1.  STATUS  OF  THIS  MEMO 

This  RFC  describes  the  details  of  the  domain  system  and  protocol,  and 
assumes  that  the  reader  is  familiar  with  the  concepts  discussed  in  a 
companion  RFC,  "Domain  Names  -  Concepts  and  Facilities"  [RFC-1034], 

The  domain  system  is  a  mixture  of  functions  and  data  types  which  are  an 
official  protocol  and  functions  and  data  types  which  are  still 
experimental.  Since  the  domain  system  is  intentionally  extensible,  new 
data  types  and  experimental  behavior  should  always  be  expected  in  parts 
of  the  system  beyond  the  official  protocol.  The  official  protocol  parts 
include  standard  queries,  responses  and  the  Internet  class  RR  data 
formats  (e.g.,  host  addresses) .  Since  the  previous  RFC  set,  several 
definitions  have  changed,  so  some  previous  definitions  are  obsolete. 

Experimental  or  obsolete  features  are  clearly  marked  in  these  RFCs,  and 
such  information  should  be  used  with  caution. 

The  reader  is  especially  cautioned  not  to  depend  on  the  values  which 
appear  in  examples  to  current  or  complete,  since  their  purpose  is 
primarily  pedagogical.  Distribution  of  this  memo  is  unlimited. 
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2.  INTRODUCTION 
2.1.  Overview 

The  goal  of  domain  names  is  to  provide  a  mechanism  for  naming  resources 
in  such  a  way  that  the  names  are  usable  in  different  hosts,  networks, 
protocol  families,  internets,  and  administrative  organizations. 

From,  the  user's  point  of  view,  domain  names  are  useful  as  arguments  to  a 
local  agent,  called  a  resolver,  which  retrieves  information  associated 
with  the  domain  name.  Thus  a  user  might  ask  for  the  host  address  or 
mail  information  associated  with  a  particular  domain  name.  To  enable 
the  user  to  request  a  particular  type  of  information,  an  appropriate 
query  type  is  passed  to  the  resolver  with  the  domain  name.  To  the  user, 
the  domain  tree  is  a  single  information  space;  the  resolver  is 
responsible  for  hiding  the  distribution  of  data  among  name  servers  from 
the  user. 

From  the  resolver's  point  of  view,  the  database  that  makes  up  the  domain 
space  is  distributed  among  various  name  servers.  Different  parts  of  the 
domain  space  are  stored  in  different  name  servers,  although  a  particular 
data  item  will  be  stored  redundantly  in  two  or  more  name  servers.  The 
resolver  starts  with  knowledge  of  at  least  one  name  server.  When  the 
resolver  processes  a  user  query  it  a  :ks  a  known  name  server  for  the 
inf orniat ion ;  in  return,  the  resolver  either  receives  the  desired 
information  or  a  referral  to  another  name  server.  Using  these 
referrals,  resolvers  learn  the  identities  and  contents  of  other  name 
servers.  Resolvers  are  responsible  for  dealing  with  the  distribution  of 
the  domain  space  and  dealing  with  the  effects  of  name  server  failure  by 
consulting  redundant  databases  in  other  servers. 

Name  servers  manage  two  kinds  of  data.  The  first  kind  of  data  held  in 
sets  called  zones;  each  zone  is  the  complete  database  for  a  particular 
"pruned"  subtree  of  the  domain  space.  This  data  is  called 
authoritative.  A  name  server  periodically  checks  to  make  sure  that  its 
zones  are  up  to  date,  and  if  not,  obtains  a  new  copy  of  updated  zones 
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from  master  files  stored  locally  or  in  another  name  server.  The  second 
kind  of  data  is  cached  data  which  was  acquired  by  a  local  resolver. 

This  data  may  be  incomplete,  but  improves  the  performance  of  the 
retrieval  process  when  non-local  data  is  repeatedly  accessed.  Cached 
data  is  eventually  discarded  by  a  timeout  mechanism. 


This  functional  structure  isolates  the  problems  of  user  interface, 
failure  recovery,  and  distribution  in  the  resolvers  and  isolates  the 
database  update  and  refresh  problems  in  the  name  servers. 

2.2,  Common  configurations 


A  host  can  participate  in  the  domain  name  system  in  a  number  of  ways, 
depending  on  whether  the  host  runs  programs  that  retrieve  information 
from  the  domain  system,  name  servers  that  answer  queries  from  other 
hosts,  or  various  combinations  of  both  functions.  The  simplest,  and 
perhaps  most  typical,  configuration  is  shown  below: 


I  queries 


Local  Host 

+  + - 

user  queries  I 

- >1  1 - 

I  Resolver  1 

< - I  l< - 

user  responses  I  I  responses 

+ - + 

I  A 

cache  additions  |  I  references 

V  I 

+ - + 

I  cache  I  I 

+ - +  I 


Foreign 
-i - 


-> 


- + 

I 

Foreign  1 
Name  I 
Server  | 


User  programs  interact  with  the  domain  name  space  through  resolvers;  the 
format  of  user  queries  and  user  responses  is  specific  to  the  host  and 
its  operating  system.  User  queries  will  typically  be  operating  system 
calls,  and  the  resolver  and  its  cache  will  be  part  of  the  host  operating 
syste.m.  Less  capable  hosts  may  choose  to  implement  the  resolver  as  a 
subroutine  to  be  linked  in  with  every  proaram  that  needs  its  services. 
Resolvers  answer  user  queries  with  information  they  acquire  via  queries 
to  foreign  name  servers  and  the  local  cache. 

Note  that  the  resolver  may  have  to  make  several  queries  to  several 
different  foreign  name  servers  to  answer  a  particular  user  query,  and 
hence  the  resolution  of  a  user  query  may  involve  several  network 
accesses  and  an  arbitrary  amount  of  time.  The  queries  to  foreign  name 
servers  and  the  corresponding  responses  have  a  standard  format  described 
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in  this  memo,  and  may  be  datagrams. 

Depending  on  its  capabilities,  a  name  server  could  be  a  stand  alone 
program  on  a  dedicated  machine  or  a  process  or  processes  on  a  large 
timeshared  host.  A  simple  configuration  might  be: 


Local  Host 


Master 


I  responses 


I  Name 
->|  Server 


queries 


Foreign 


-> I F  oreign  | 
I  Resolver  1 
-- 1  I 


Here  a  primary  name  server  acquires  information  about  one  or  more  zones 
by  reading  m.aster  files  from  its  local  file  system,  and  answers  queries 
about  those  zones  that  arrive  from  foreign  resolvers. 

The  DNS  requires  that  all  zones  be  redundantly  supported  by  more  than 
one  name  server.  Designated  secondary  servers  can  acquire  zones  and 
check  for  updates  from  the  primary  server  using  the  zone  transfer 
protocol  of  the  DNS.  This  configuration  is  shown  below: 


Local  Host 


I  Master  I -- 
I  files  I  ! 


Namie 

Server 


I  responses 


queries 


! maintenance 


queries 


Foreign 


-> I  Foreign  | 
I  Resolver | 


->l  I 

I  Foreign  | 
1  Name  I 
-- I  Server  I 


maintenance  responses  I  + - + 

In  this  configuration,  the  name  server  periodically  establishes  a 
virtual  circuit  to  a  foreign  name  server  to  acquire  a  copy  of  a  zone  or 
to  check  that  an  existing  copy  has  not  changed.  The  messages  sent  for 
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these  maintenance  activities  follow  the  same  form  as  queries  and 
responses,  but  the  message  sequences  are  somewhat  different. 

The  information  flow  in  a  host  that  supports  all  aspects  of  the  domain 
name  system  is  shown  below: 


Local  Host 

+ - 4- 

I  i  user  queries 

User  i - 

i  Program  i 


I  queries 


i  Master 
files 


- >1 

1 

< - 1 

user  responses [ 

Resolver 

1 - 

[ 

l< - 

[ responses 

cache  additions 

1  A 

[  [ 

V  [ 

references 

1  Shared  [ 

[  database  [ 

refreshes 

/  1 

A  [ 

1  [ 

[  V 

references 

1  1 

1  [ 

- >[ 

Name 

Server 

1  responses 

[ - 

[ 

queries 


[maintenance 


queries 


maintenance  responses 


Foreign 

+ - + 

I  I 

->1 Foreign  j 
I  Name  I 
--[  Server  | 


-> [Foreign  [ 

( Resolver  I 
--  I  I 

+ - + 


[Foreign  [ 

I  Name  I 
-  I  Server  | 
+ - + 


The  shared  database  holds  domain  space  data  for  the  local  name  server 
and  resolver.  The  contents  of  the  shared  database  will  typically  be  a 
mixture  of  authoritative  data  maintained  by  the  periodic  refresh 
orations  of  the  name  server  and  cached  data  from  previous  resolver 
quests.  The  structure  of  the  domain  data  and  the  necessity  for 
synchronization  between  name  servers  and  resolvers  imply  the  general 
ch.a  racterist  ics  of  this  database,  but  the  actual  format  is  up  to  the 
local  implementor. 
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Information  flow  can  also  be  tailored  so  that  a  group  of  hosts  act 
together  to  optimize  activities.  Sometimes  this  is  done  to  offload  less 
capable  hosts  so  that  they  do  not  have  to  implem.ent  a  full  resolver. 

This  can  be  appropriate  for  PCs  or  nosts  which  want  to  minimize  the 
amount  of  new  network  code  which  is  required.  This  scheme  can  also 
allow  a  group  of  hosts  can  share  a  small  number  of  caches  rather  than 
.maintaining  a  large  number  of  separate  caches,  on  the  premise  that  the 
centralized  caches  will  have  a  higher  hit  ratio.  In  either  case, 
resolvers  are  replaced  with  stub  resolvers  which  act  as  front  ends  to 
resolvers  located  in  a  recursive  server  in  cne  or  more  name  servers 
known  to  perform  that  service: 


Local  Hosts 

+ - + 

I  I  responses 

!  Stub  !< - + 

i  Resolver (  | 

1  I - +  I 

+ - +  recursive  I  I 

queries  1  1 

V  ! 

+ - +  recursive  + - + 

i  I  queries  I  [queries 

i  Stub  I - >1  Recursive  1 - 

I  Resolver  I  I  Server  I 

I  l< - I  l< - 

+ - +  responses  I  I  responses 

+ - + 

I  Central  I 

I  cache  I 

+ - + 


Foreign 


I 

-> I  Foreign 
I  Name 
-- I  Server 


In  any  case,  note  that  doitain  components  are  always  replicated  for 
reliability  whenever  possible. 

2.3.  Conventions 

The  domain  system  has  several  conventions  dealing  with  low-level,  but 
f undamiental ,  issues.  While  the  implementor  is  free  to  violate  these 
conventions  WITHIN  HIS  OWN  SYSTEM,  he  must  observe  these  conventions  in 
ALL  behavior  observed  from  other  hosts. 

2.3.1.  Preferred  name  syntax 

Trie  DNS  specifications  attem.pt  to  be  as  general  as  possible  in  the  rules 
for  constructing  domain  names.  The  idea  is  that  the  name  of  any 
existing  object  can  be  expressed  as  a  domain  nam.e  with  minimal  changes. 


;kapet  r is 
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However,  when  assigning  a  domain  name  for  an  object,  the  prudent  user 
will  select  a  name  which  satisfies  both  the  rules  of  the  domain  system 
3r:l  any  existing  rules  for  the  object,  whether  these  rules  are  published 
or  implied  by  existing  programs. 

For  e.xample,  when  naming  a  mail  domain,  the  user  should  satisfy  both  the 
rules  of  this  memo  and  t.hose  in  RFC-822,  When  creating  a  new  host  name, 
the  old  rules  for  HOSTS.TXT  should  be  followed.  This  avoids  proble.'^is 
when  old  software  is  converted  to  use  dom.ain  namies . 

.-he  follcwi.ng  synta.x  will  result  in  fewer  problems  with  many 

?.cp  i  i  cat  ions  that  use  dorr;ain  .names  (e.g.,  m.ail,  TFl.'.'ZT)  . 

<'d;m.ain>  <subdomain>  1  "  " 

<hsubdorr.ain>  :;=  <label>  I  <subdomain>  "  .  ”  <label> 

<i:ibei>  <Jetter>  [  [  <ldh-str>  ]  <let-dig>  j 

<idh-str>  <let-dig-hYp>  |  <let-dig-hyp>  <ldh-str> 

< let -dig-hyp>  :;=  <let-dig>  1 
<iet-d^g>  ::=  <letter>  |  <digit> 

<letter>  : :=  any  one  of  the  52  alphabetic  characters  A  through  Z  in 
upper  case  and  a  through  z  in  lower  case 

'.digit'>  any  one  of  the  ten  digits  0  through  9 

Note  that  while  upper  and  lower  case  letters  are  allowed  in  domain 
names,  no  significance  is  attached  to  the  case.  That  is,  two  names  with 
the  same  spelling  but  different  case  are  to  he  treated  as  if  identical. 

The  labels  rr/ust  follow  the  rules  for  ARPAllET  host  names.  They  must 
siart  with  a  letter,  end  with  a  letter  or  digit,  and  have  as  interior 
o.'.aracters  only  letters,  digits,  and  hyphen.  There  are  also  some 
restrictions  on  the  length.  Labels  must  be  63  characters  or  less. 

For  example,  the  following  strings  identify  hosts  in  the  Internet: 

A.:.:i.ED';  xx .  lcs  ..mit  .  edu  sri-nic.arpa 

1.3.2.  Data  Transmdssion  Order 

The  order  of  transmdssion  of  ?  header  and  data  described  in  this 
i  co.T.er.’:  i  .s  resolved  to  the  octet  level.  W.henever  a  diagram  shows  a 
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group  of  octets,  the  order  of  transm-.iss  icin  of  those  octets  is 
order  in  which  they  are  read  in  Fnglish.  For  example,  in  the 
diagrarr.,  tha  octets  arc  t  r  ansm.itted  in  the  order  they  are  nu:i 

34ofc':'S10l2345 

-  ^ 

- , - - 1-  — 

3  4.1 

5  i  b  j 

■4 - - +  - + 

Whenever  an  octet  represen*:s  a  numeric  quantity,  the  left  most  bit  in 
the  diagrarr.  rs  the  high  order  or  most  significant  bit.  That  is,  the  but 
labeled  C  is  the  rr.ost  ‘significant  bit.  For  example,  the  follo'.-ing 
diagra.m  represents  the  value  170  (decimal)  . 

C  1  2  3  4  5  6  7 

+  —  +  —  +  —  -f  — 

110101010! 

+  -  +  _C_4._  +  _.f  _+_  +  _  + 


the  normal 
f  ill-owing 
m.  e  r  e  d  . 


Similarly,  whenever  a  multi-octet  field  represents  a  nu.neric  quantity 
the  left  most  bit  of  the  wh-ole  field  is  the  most  significant  bit.  I'lnen 
a  m.ulti-octet  quantity  is  transmitted  the  m.o.st  significant  octet  is 
transm.itted  first. 

2.3.3.  Character  Case 


the  official  protocol. 


Labels,  domain  nan.es,  etc.) 


F  o dll  parts  of  the  DN’S  that  are  part  c 
com.pa r  i.s  ons  between  cnaracter  strings  a 
are  uone  in  a  case-insensitive  manner.  At  oresent,  this  rule  is  in 
force  throughout  the  -d-omain  system  without  ez-oceptior* .  However,  future 
additior.s  beyond  current  usage  may  nc-e-d  to  use  the  full  binary  octet 


oapabilities  in  namies. 


so  attempts  to  store  dorr.ain  narr.os  in 


'-bit  AS( 


special  bytes  to  terminate  labels,  etc 


should  be  avoided. 


When  data  en'-ers  the  dom.ain  system,  its  original  case  should  be 
preserved  whenever  possible.  In  certain  circumstances  this  cannot  be 
done.  cor  example,  if  two  RRs  are  stored  in  a  -databaue,  one  at  x.y  and 
one  at  X.Y,  they  are  actually  stored  at  the  same  place  in  the  dat.ibase, 
and  henoo  only  one  casing  would  be  preserved.  Tne  basic  rule  is  that 
ca.se  can  be  discarded  only  when  data  is  use-d  to  define  struc'^uie  ir,  a 
database,  and  two  nam.es  are  identical  whe.f'i  ccrrpar»-d  in  a  case 
insensitive  manner. 
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;3  :  r:  case  ser.oc.  r  ive  data  must  be  .T.ini.'iiized .  Thas  while  data  for  x.y 
;  X.y  "  ay  .t:tr.  be  stcred  u.ndGr  a  single  locat  ic.n  x.y  or  X.Y,  data  for 
;  a:.;i  b.X  w :: u  1  i  never  be  stored  under  A. -a,  A.X,  b.x,  or  b.X.  In 
.eral,  preserves  the  case  ob  the  first  label  of  a  domai:!  na.Cie, 

force.s  standardization  or  interior  node  labels. 

t’O.'ts  a i  r.  0  s  t  i  a  t  o  .'S  who  e.nter  data  i.ntc  the  d'O.T.ai.n  database  s.hould 
O-ire  to  repre,sent  the  data  they  supply  to  the  d'~.Tain  systerr'.  ’n  a 
e  -  0  o.t  ^  1 3 1  e.-.t  rr.anner  if  their  system  is  case-ser.sitive  .  The  data 
tritution  system  i.n  the  d...miain  system  wili  ensure  tiiat  consiste.nt 
re  .ien  t  a  t  1 ;  r.  s  are  preserved. 


0  an::;  parameters  in  the  DN’S  have  size  limits.  They  ait 
o 0 m.e  cou.-u  oe  easiiy  changed,  ot.ners  are  more 

to  ootets  or  less 

positive  values  of  a  signed  32  bit  numier. 
ol2  octets  or  ^ess 


JrACE  AMD  RP  liEFIKITIONS 


.  -  .  ..arte 


.o.ain  na.' 


in  .'T.essages  are  expressed  iri  tert.s  ol  a  sequence  of  labels 
represented  as  a  one  O'Ctet  length  field  followed  by  that 
et.s.  Since  every  d.  air.  name  ends  with  the  null  label  of 
0.0.3  1.1  .na.me  is  terminated  by  a  length  .oyt:-  of  zero.  The 
0  bits  of  ev<-,-ry  length  octet  must  be  zero,  and  the 
bits  t.f  t.ne  ler.'jth  field  ii.mit  the  label  to  fi3  octets  or 


;  ar.'d  ianel  ^er.gth 


ength  of  a  oo 


.amain  nar.,e  (i.e., 
:o  255  octets  or 


o  .  x:o;io  out  ot.t*.ain  ar.y  ^  :  ;t  values  in  ootv*;.!  that  make  up  a 
,  ;  itrtrgly  re  ;  ornter.  ded  tha*i  labels  f'll  biw  the  preferred 


a  oa  :ie  -  ; :. 


harte  servers  an;  lo.'oivers  must 
ve  mar.ner  (i.e.,  A^a),  aoourting  Ai 


i  P  a  u'  e 
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KK  oe r 1" 1 t ions 


.-.Kr  r.ove  toe  san;e  toe  ^eve^  lornat 


s  h  c  w  n  b  e  1  o  w  ; 


-4- - r- - - 4- 


-4 - * - 4  - 


.  4  _  _  +  _  _  4- _  _  +  -  -  4  . 


)  LENGTH 


PLATA 


wr.er  r.arr.e,  i.e.,  the  narte  of  the  node  to  wh ict 
■.■roe  record  pertains. 

octets  containing  one  cf  the  RR  TYPE  codes. 

octets  ccr.ta in i.ng  one  of  the  RR  CLASS  codes. 

bit  signed  integer  that  specifies  the  tirr.e  ir 
ti.e  rccocrce  record  nay  be  cached  before  the 
he  i .t f : raa t ion  should  again  be  consulted.  Zei 
e.s  are  interpreted  to  rriean  that  the  RR  can  or.j 
for  ohiG  t. r 3 iiS 5 c 0 i on  in  progrGSs,  sri'^d  should  r 
ed.  For  exarr.ple,  SGA  records  are  always  dist: 
a  zero  TIL  to  prohibit  caching.  Zero  values 
be  used  for  e;-:t  re.T.e  iy  volatile  data. 

.osigned  16  bit  integer  that  specifies  the  lone 
t  .'3  of  the  .PLATA  field. 


MO'  0  0 


[Faqe  11 
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RDATA  a  variable  length  string  of  octets  that  describes  the 

resource.  The  format  of  this  information  varies 
according  to  the  TYPE  and  CLASS  of  the  resource  record. 


3.2.2.  TYPE  values 

TCP."  fields  are  used  in  resource  records.  Note  that  these  types  are  a 
subset  of  QTYPEs  . 

7i?E  value  and  meaning 

.A  1  a  host  address 

N’S  2  an  authoritative  name  server 


V' 


N'  • 


2  :a 


.MR 


3  a  mail  destination  (Obsolete  -  use  MX) 

4  a  iTiail  forwarder  (Obsolete  -  use  MX) 

5  the  canonical  na.me  for  an  alias 

6  mat'<s  the  start  of  a  zone  of  authority 

7  a  m.ailbox  domain  name  (EXPERIMENT.AL) 

8  a  mail  group  member  (EXPERIMENTAL) 

9  a  mail  rename  domain  name  (EXFERIMEtJTAL) 

10  a  null  RR  (EXPERIMENTAL) 

11  a  well  jr.nown  service  description 

12  a  domain  na.me  pointer 

13  host  information 

14  mailbox  or  mail  list  information 

15  mail  exchange 

16  text  strings 


va 1 ues 


Ids  appear  in  the  question  part  of  a  query. 
)f  TYPE',3,  hence  ail  TYPES  are  valid  QTYPEs  . 
QTYPE.s  are  defined: 


QTYPES  are  a 
In  addition,  the 
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AXFR 

252 

A 

request 

for 

a  transfer  of  an  entire 

zone 

y  t  C  3 

253 

A 

request 

for 

mailbox-related  records 

(MB,  MG  or  MR) 

MA:  LA 

2  54 

A 

request 

for 

mail  agent  RRs  (Obsolete 

-  see  MX) 

r 

255 

A 

request 

for 

all  records 

^.2.4.  CLACC 

va  lues 

CL.AS5  fields 

appear 

in 

resour 

ce  records.  The  following  CL 

ASS  .m.n  e  m  c  n  i  c  s 

ar.i  values  are  defined; 


1  the  Internet 


2  the  C3Nr.T  class  (Obsolete  -  used  only  for  e;-;arr.ples  in 
some  obsolete  RFCs) 


CH  3  tr.e  CHAOS  class 

H£  4  Hesiod  [Dyer  87] 

3.2.5.  'ICl.eSS  values 

QCD.^SS  fields  appear  in  the  question  section  of  a  query.  QCLASS  values 
are  a  superset  of  CLASS  values;  every  CLASS  is  a  valid  QCLASS.  In 
addition  to  CLASS  values,  the  following  QCLASSes  are  defined: 

^  255  any  class 

3.3.  Standard  RRs 

The  following  RR  defiiiltions  are  expected  to  occur,  at  least 
potentially,  in  all  classes.  In  particular,  NS,  SOA,  CNAL'.E,  and  PTR 
will  be  used  in  all  classes,  and  have  the  same  format  in  all  classes. 
Because  their  RLATA  format  is  known,  all  domain  names  in  the  RDATA 
section  of  these  RRs  may  be  compressed. 


hdo.ma in-r..a.m.e>  is  a  domiain  name  represented  as  a  series  of  labels,  and 
te  rmi.nated  by  a  label  with  zero  length.  <character-st  r  ing>  is  a  single 
length  octet  followed  by  that  nurtiber  of  characters.  <character-string> 
is  treated  as  binary  information,  and  can  be  up  to  256  characters  in 
length  {including  the  length  octet) . 
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1  .  CNAME  RDATA  format 

+  +  +  +  +  +  +  +  +  +  +  +  +  - + 

CNAME  / 

/ 


a  <dorriain-r'.am.e>  which  specifies  the  canonical  or  primary 
name  for  the  owner.  The  owner  name  is  an  alias. 

CNC-C-IE  RRs  cause  no  additicnal  section  processing,  but;  naine  servers  may 
cr.  .'.use  to  re.soart  the  query  at  t.he  canonical  na.me  in  certain  cases.  See 
t^-.e  description  of  name  server  logic  in  tRFC-1034]  for  details. 

3.3.2.  HINFO  RDATA  format 


C?'.;  A  <character-string>  which  specifies  the  CPU  type. 

IS  A  <character-strir.g>  which  specifies  the  operating 

system  type. 

.Standard  values  for  CPU  and  OS  can  be  found  in  [RFC-IOIO]  . 

HINFO  records  are  used  to  acquire  general  information  about  a  host.  The 
.m.ain  u.se  is  for  protocols  such  as  FTP  that  can  use  special  procedures 
when  talking  between  machines  or  operating  systems  of  the  came  type. 

3.3.3.  MB  RDATA  format  (EXPERIMENTAL) 

MJ\Dr-;.a>;E  / 

/  / 

- + - +  +  +  +  +  +  +  + 


.MADr;/dkL 


A  <doma in-nam,e>  which  specifies  a  host  which  has  the 
specified  mLailbox. 


•Mockapet  ris 


[Page  14] 


Domain  Names  -  Implementation  and  Specification 


RFC  1035 


RFC  1035  Domain  Implementation  and  Specification  November  1987 


MB  records  cause  additional  section  processing  which  looks  up  an  A  type 
P.Rs  corresponding  to  MADNAl’.E . 

3.3.4.  .M,D  RDATA  format  (Obsolete) 

/  M-ADNAMiE  / 

/ 

where  ■. 

M..i..CN.rC';£  A  <dcma i.n-nam.e>  which  specifies  a  host  ’which  has  a  rrail 

agent  for  the  domain  which  should  be  able  to  deliver 
mail  for  the  domain. 

.^!D  records  cause  additional  section  processing  which  looks  up  an  A  type 
record  corresponding  to  MADNAME . 

MD  is  obsolete.  See  the  definition  of  MX  and  [RFC-974]  for  details  of 
the  new  scheme.  The  recommended  policy  for  dealing  with  MD  RRs  found  in 
a  master  file  is  to  reject  therni,  or  to  convert  them  to  MX  RRs  -with  a 
preference  of  0  . 

3.3.5.  MF  RD-’ATA  format  (Obsolete) 

./  MADNAME  / 

/  / 

whe  re  : 

MADNAME  A  <doma in-r.am,e>  which  specifies  a  host  which  has  a  mail 

agent  for  the  domain  which  will  accept  mail  for 
forwarding  to  the  domain. 

MF  record.s  cause  additional  section  processing  which  looks  up  an  A  type 
record  corresponding  to  MADNAME. 

MF  is  obsolete.  See  the  definition  of  MX  and  [RFC-974]  for  details  ofw 
t.he  ne'w  scheme  .  The  recommended  policy  for  dealing  with  MD  RRs  found  in 
a  miaster  file  is  to  reject  them,  or  to  convert  them  to  MX  RRs  with  a 
preferer’.ce  of  10. 


Mockapet  r is 
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3.3.0.  MG  RD.R^A  format  (EXPERIMENTAL) 

+  -  +  +  +  +  +  + 

/  MGMNAME 

+ - » - .f - -t - .r - + - + - + - T - + - H - H - + - + 


A  <dtma ir;-na.m.e>  which  specifies  a  m.ailbox  which  is  a 
.memhoer  of  the  m.ail  group  specified  by  the  domain  narrie  . 

.XC  record?  cause  no  additional  secti.on  process  i  r.g  . 

C.3.'.  MINES  PLATA  format  (EXPERIMENTAL) 

- ^ +  -  -  +  --  +  --.r--  + 

/  PLIAILEX  / 

- - - - '> - ^  + - + - 1 - H - i - 1 - - 1 —  —  H - - - * 

EMAIL3X  / 

- - 4- - t - -f - f - -t- - + - -f - H - i - 1 - -+ - 1 - 1- - + - 1 - -t 


I'MAILBX  A  <domain-narre>  which  specifies  a  rriailbox  which  is 

responsible  for  the  mailing  list  or  mailbox.  If  this 
domain  .narrie  .names  the  root,  t.he  owner  of  the  MINED  RR  is 
responsible  for  itself.  Note  that  many  existing  mailing 
lists  use  a  .miailbox  X-request  for  the  RM/.ILBX  field  of 
m.ailir.g  list  X,  e.g.,  Msgroup- request  for  Msgroup.  This 
field  provides  a  more  general  mechanism. 


EM.AIL3X  A  vdomiain-name>  which  specifies  a  rrailbox  which  is  to 

receive  error  messages  related  to  the  mailing  list  or 
.mailbox  specified  by  the  owner  of  the  MINED  RR  (similar 
to  the  ERRORS-TO:  field  which  has  been  proposed) .  If 
this  domain  name  na.mes  the  root,  errors  should  be 
returned  to  the  sender  of  the  message. 

MINED  recor.is  cause  no  additional  section  processing.  Although  these 
records  can  be  associated  with  a  simple  m.ailbox,  they  are  usually  used 
wich  a  mailing  list. 
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3.3.8.  MR  RDATA  format  (EXPERIMENTAL) 

i  NEWNAME 

/ 

+  +  +  +  - +  + 

w.te re  ; 

NEWNAME  A  <doma  in-narr',e>  w.Nich  specifies  a  mailbox  which  is  the 

proper  rename  cf  the  specified  mailbox. 

MR  records  cause  no  additional  section  processing.  The  main  for 

is  as  a  forwarding  entry  for  a  user  w.ho  has  moved  to  a  differe.nt 
mailbox 

3.3.9.  MX  RDATA  format 


/ 

/ 


— 

--F- 

-  +  i- > 

—  T  — 

-  r- 

— r  — 

-  +  - 

— 

1 

PREFERENCE 

1 

-r  - 

—  4" - — 

-  -t-  -  -  r- 

— f  — 

-r - f - f - + 

-  4-  — 

—  -r  — 

—  -f.  _ 

—  -r  — 

-  +  - 

-  +  - 

-  + 

/ 

EXCK.ANGE 

/ 

/' 

/ 

-h  — 

-f 

-  ^  _  4-  , 

-  i-  - 

-•f - + - + 

-  +  “ 

-  4-  - 

-  +  - 

-  + 

whe  re  ; 

PREFERENCE  A  16  bit  integer  which  specifies  the  preference  given  tc 

this  RR  among  others  at  the  same  owner.  Lower  values 
are  preferred. 

EXCHANGE  A  <doma in -name>  which  specifies  a  host  willing  to  act  as 

a  mail  exchange  for  the  owner  name. 

MX  records  cause  type  A  additional  section  processing  for  the  host 
.specified  by  EXCHANGE.  The  use  of  MX  RRs  is  e.xplained  in  derail  in 
(RFC- 971]. 

3. 3.  1C.  NULL  RDATA  format  (EXPERIMENTAL) 


+  --  *-  --*---4---  +  --  +  --  +  --  +  --  +  --  +  --  +  --  +  --  +  --  +  --  + 

/  <anything> 

/ 

-F - t- - ^ - - + - + - + - 1 - 1 - + - 1 - + - i - -t - h 


/ 

/ 


Anything  at  all  .may  be 
or  less  . 


the  PHATA  field  so  long  as  it 


65535  octets 


Mocicapet  r  is 
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records  cause  no  additional  section  processing.  NULL  RRs  are  not 
allo'.'/ed  in  master  files.  NULLs  are  used  as  placeholders  in  some 
e.xperirr.ental  e.xtensions  of  the  DNS. 

3.3.11.  NS  PbATA  format 

- - - + - 4 - I - y. - i - -j - -j - y. - 4. - ^ - ,1 - ^ - ^ - ..j - ^ 

/ 

- r - - - - 1 - r - -I - f - f - 1 - i - r - + - -i - + - H - + 


NSLL'.’l-'F  A  <dcma in-name>  which  specifies  a  host  which  should  be 

authoritative  for  the  specified  class  and  domain. 

NS  records  cause  both  the  usual  additional  section  processing  to  locate 
a  type  A  record,  and,  when  used  in  a  referral,  a  special  search  of  the 
zone  in  which  they  reside  for  glue  information. 

Ihe  NS  RR  states  that  the  named  host  should  be  expected  to  have  a  zone 
starting  at  owner  name  of  the  specified  class.  Note  that  the  class  may 
nut  indicate  the  protocol  family  which  should  be  used  to  communicate 
with  the  host,  although  it  is  typically  a  strong  hint.  For  example, 
hosts  which  are  name  servers  for  either  Internet  (IN)  or  Hesiod  (HS) 
class  inf  orrr.at  ion  are  norrrially  queried  using  IN  class  protocols. 

3.3.12.  FTR  RD'ATA  fcrm.at 

f--+- 

/  PTPX)NAME  / 

whe  re ; 

PT.^DNAdiE  A  <doma in-nam,e>  which  points  to  some  location  in  the 

domain  name  space. 

PTR  records  cause  no  additional  section  processing.  These  RRs  are  used 
in  special  domains  to  point  to  some  other  location  in  the  domain  space. 
These  records  are  simple  data,  and  don't  imply  any  special  processing 
similar  to  that  performed  by  CNAME,  which  identifies  aliases.  See  the 
description  of  the  IN-ADDR.ARPA  domain  for  an  exam.ple. 
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A  format 


--*----  +  --  +  --  +  ---*---4- 


FjNA.ME  / 

SERIAL  I 


REFRESH 


•  + - 1-  —  +  —  t-  —  4-  —  + 


-4 - +  + 


- h - H - 4- - i - 4 - 1- - h- 

EXFIRE 


-4~-4---  +  -'-  +  --4-'--4--  +  - 


MINIMUM 


■  --4  --4- 


'4  —  —  +  “'  —  4  —  —  4'-  —  4 


The  <dor.a ir.-r.arr,e>  of  the  r.arr.e  server  that  was  tr.e 
original  or  primary  source  of  data  for  this  zone. 

A  <dO‘rriair.-r.arre>  which  specifies  the  mailbox  of  the 
person  responsible  for  this  zone. 

The  unsigned  32  bit  version  numiber  of  the  original 
of  the  zone.  Zone  transfers  preserve  this  value, 
value  wraps  and  should  be  com'pared  usi.ng  sequence  j 
arithmetic . 

A  32  bit  ti.Tie  interval  cefere  the  zone  should  be 
re  f  reshed . 

A  32  bit  t  im.e  interval  that  should  elapse  before  a 
failed  ref.’res.h  should  be  retried. 

A  32  bit  time  value  that  specifies  the  upper  limit 
the  time  i.ntervai  that  can  elapse  before  the  zone  i 
longer  authoritative. 
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rne  unsigned  32  bit  minimum  TTL  field  that  should  be 
exported  with  ar.v  RR  from  this  zone. 


ts^ris  sause  nc  additional  section  processing 
■Ir'.es  are  rn  units  of  seconds. 


the  M; 
i  on  t 
:m1'M  sr 


.ge  the 


toe  freldo  are  pertinent  only  for  r.ar:,e  server  maintenance 
■•iowever,  MINIMUM  is  used  in  all  query  oneratio.ns  that 
-03  from  a  zone.  V.'he.never  a  P.R  is  sent  in  a  response  to  a 
I'7t  field  is  set  to  the  rriaximu.m  of  the  Tl’L  field  from  t.he  RR 
NIMU.M  field  in  the  appropriate  SO.A..  Th.us  MINIMUM  is  a  lower 
he  TTL  field  for  ail  RRs  in  a  zotie .  Ihote  that  this  use  of 
ouid  occur  when  the  RRs  are  copied  into  the  response  and  not 
one  is  loaded  from  a  master  file  or  via  a  zone  transfer.  The 
this  provison  is  tc  allow  future  dynamre  update  facilities  tc 
30.-'..  RR  with  known  semantics. 


*  1  .  lA.  .-<.,.-<..•3  format 


T  XT  “ .'iT  A 


One  or  iT’.ore  <ch3  r acte r-st  r  ir.g>s  . 


R.Rs  are  used  to  nol-d  descriptive  text, 
■ends  on  the  do.main  where  it  is  fou.nd. 

.  Internet  specific  RRs 


1.  A  RLATA  format 


- t  -  -  f  - 

ADDRESS 


A  32  bit  Inter.net  address. 


jltiple  Ini:  erne? 


addresse.s  will  have  multiple  A 
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A  records  cause  no  additional  section  processing.  The  RDATA  section  of 
an  A  lii.e  in  a  master  file  is  an  Internet  address  expressed  as  four 
decimal  n.^:ri:er3  separated  by  dots  without  any  iiribedded  spaces  (e.g., 

"10 . 2  .  0  .  52"  cr  " 1 92 . 0 . 5  .  6" j  . 

3.4.2.  vnKS  RIjATA  format 

+  --* - +  +  +  +  +  - +  + 

1  -Ali'D-RESS 

r b -t -» - f- i"-  —  -t- +  —  — {- 1 —  -*4-  —  — r i - f- h 

1  PROTOCOL  I 

T - t- - + - +  — - - - - - F - -t 

<b:t  maf> 

wf’ie  re  : 

ACDRES3  An  32  bit  I.nternet  address 

PROTOCOL  An  8  bit  IP  protocol  number 

OIT  MAr>  A  variable  length  bit  map.  The  bit  map  must  be  a 

multiple  of  8  bits  long. 

The  WKS  record  is  used  to  describe  the  well  k.nown  services  supported  by 
a  particular  protocol  on  a  particular  internet  address.  The  PROTOCOL 
field  specifies  an  IP  protocol  number,  and  the  bit  map  has  one  bi*"  per 
pert  of  the  specified  protocol.  The  first  bit  corresponds  to  port  C, 
the  second  to  port  1,  etc.  If  the  bit  map  dees  not  include  a  bit  for  a 
prctoccl  of  interest,  that  bit  is  assumed  zero.  The  appropriate  values 
and  rri.ne monies  for  ports  and  protocols  are  specified  in  (RFC-1010]. 

For  example,  if  PROTOCOL=TCP  (6),  the  26th  bit  corresponds  to  TCP  port 
25  (CMTP) .  If  this  bit  is  set,  a  SMTP  server  should  be  listening  on  TCP 
pert  25;  if  zero,  SMTP  service  is  not  supported  on  the  specified 
a idress . 


The  purpose  of  WKS  RRs  is  to  provide  availability  information  for 
.server^  for  TCP  ?.nd  UDP  .  It  R  .server  supports  both  TCP  and  UDP,  or  has 
multiple  Internet  addresses,  then  multiple  WKS  RRs  are  used. 

WKS  RRs  cause  no  additional  section  processi.ng. 

In  master  files,  both  ports  and  protocols  are  e.xpressed  using  mnemonics 
or  decimal  numbers. 
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J.5.  IN-.AS^DR  .  ARPA  domain 

The  Internet  uses  a  special  domain  to  support  gateway  location  and 
Ir.ternet  address  to  host  mapping.  Other  classes  may  employ  a  similar 
strategy  in  other  domains.  The  intent  of  this  domain  is  to  provide  a 
guaranteed  method  to  perform  host  address  to  host  name  mapping,  and  to 
racrlitate  queries  to  locate  all  gateways  on  a  particular  network  in  the 
r,  t  e  r  net 

^.■'te  that  both  of  these  services  are  similar  to  functions  that  could  be 
p'Orf'rmed  by  inverse  queries;  the  difference  is  that  this  part  of  the 
it.T.ai.n  .name  space  is  structured  according  to  address,  and  hence  can 
gunirantee  that  t.ne  appropriate  data  can  be  located  without  a.n  exhaustive 
Sear  ill  of  the  domain  space. 


3  at  I.'.'-.ADii.R  .  ARPA  and  has  a 
tessi nq  structure. 


■■structure  wiiich  foil''. 


itmair.  namies  in  the  IN-ADDR .  .ARPA  domain  are  defined  to  nave  up  to  four 
labe'  .  in  addition  to  the  IN-A.DuR . ARPA  suffix.  Each  label  represents 
::'.e  octet  of  an  Internet  address,  and  is  expressed  as  a  character  string 
f : r  a  decimal  value  in  the  range  G-255  (with  leading  zeros  omitted 
e.'-ncept  i.t  the  case  of  a  zero  octet  which  is  represented  by  a  single 

Host  addresses  are  represented  by  domain  names  that  have  all  four  labels 
specified.  Thus  data  for  Internet  address  10.2.0.52  is  located  at 
demein  namie  52 . 0  .  2  . 1 0  .  IN-AD-DR .  ARPA .  The  reversal,  though  awkward  to 
read,  allows  zones  to  be  delegated  which  are  exactly  one  network  of 
address  space.  For  o^ample,  1 0 . IN-ADDR . ARPA  can  be  a  ’one  containing 
data  for  the  ARPANET,  wh^le  2 6 . IN-ADDR . ARPA  can  be  a  separate  zone  for 
.NIL.NET.  Address  nodes  are  used  to  hold  pointers  to  primary  host  names 
in  the  normal  domain  .space. 

N’etwork  numbers  corresrond  to  some  ncn-terminal  nodes  at  various  depths 
in  the  IN-ADDR. ARPA  doruain,  since  Internet  network  nu-cibers  are  either  1, 
2,  or  3  octets.  Network  nodes  are  usad  to  hold  pointers  to  tlie  primary 
ho,3t  names  of  gateways  attached  to  t.hat  network.  Since  a  gateway  is,  by 
'ii  f  i  n  it  ion ,  on  more  than  one  network,  it  will  typically  have  two  or  more 
net-work  nodes  which  point  at  it.  Gateways  will  also  .have  host  level 
P'' inters  at  their  fully  qualified  addresses. 

Both  the  gateway  pointers  at  network  nodes  and  the  normal  host  pointers 
at  full  address  nodes  use  the  PTR  RP  to  point  back  to  the  primary  domain 
r.a.me.s  of  the  corresponding  hosts. 

FO'r  example,  the  IN-ADDR .  ARPA  domain  will  contain  information  about  the 
I  I  gateway  between  net  10  and  26,  an  MIT  gateway  from  net  10  to  MIT's 
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net  18,  ana  hosts  A.ISI.ED'J  and  MoLTICS.MIT.EDU.  Assuming  tlnat  ISI 
ateway  has  addresses  1C.  2.  0.22  and  26.0.0.103,  and  a  name  MILNET- 
W.ISI.EIU,  an’  the  MIT  gateway  has  addresses  10.0. 0.77  and  18.10.0.4 
r.d  a  .nam.e  GW .  LCS  .  .MIT  .  EDU,  tire  domain  database  would  contain; 

PTR  MI LNET-GW .ISI. EDU . 

F  TR  GW  .  LC3  .  .MIT  .  EDU  . 

PTR  GW.LCS.MIT.EDU. 

PTR  MILNET-GW.ISI.EDU. 

PTR  MILNET-GW. ISI . EDU. 

PTR  MILNET-GW. ISI . EPU . 

PTR  GW.LCS  MIT.EDU. 

PTR  GW.LCS  ..MIT.EDU. 

PTR  A. ISI -EDU. 

PTR  .MULTICS.MIT.EDU. 

h.us  c.  orogram.  whicli  wanted  to  locate  gatev.ai.s  on  net  10  would  origrr.ate 
quer'y  of  the  form  QTY?E  =  PTR,  QCLASS=IN,  QNAME=10  .  IN-.ADDR .  ARPA .  It 
ouia  receive  two  RRs  i.n  response; 

10 . IN-ADDR. ARPA.  PTR  MILNET-GW.ISI.EDU. 

10 . IN-ADDR. ARPA.  PTR  GW.LCS.MIT.EDU. 

he  program  could  then  originate  QTyPE=A,  QCLASS=IN  queries  for  MILNET- 
W. ISI.EDU.  and  GW.LCS.MIT.EDU.  to  discover  the  Internet  addresses  of 
these  gateways  , 

A  resolver  which  wanted  t-^  find  the  host  name  corresponding  to  Internet 
host  address  10.0.0.6  would  pursue  a  query  of  the  form  QTYPE=PTR, 
QCLASS=IN,  QNAME=6 . 0 . 0 . 1 0 . IN-ADDR . ARPA,  and  would  receive; 

6 . 0 . 0 . 10 . IN-ADDR. ARPA.  PTR  MULTICS.MIT.EDU. 

Several  cautions  apply  to  the  use  of  these  services: 

-  Since  the  IN-ADDR. ARPA  special  domain  and  the  normal  domain 
for  a  particular  host  or  gateway  will  be  in  different  zones, 
the  possibility  e.xists  that  that  the  data  may  be  inconsistent. 

-  Gateways  will  often  have  two  names  in  separate  domains,  only 
one  of  which  can  be  primary. 

-  Syst  ems  that  use  the  domain  database  to  initialize  their 
rcu.ing  tables  must  start  with  enough  gateway  information  to 
guarantee  that  they  can  access  the  appropriate  name  server. 

-  The  gateway  data  only  reflects  the  existence  of  a  gateway  in  a 
manner  equivalent  to  the  current  HOSTS.TXT  file.  It  doesn't 
replace  the  dynamic  availability  information  from  GGP  or  EGP . 


^  .  .  IN— .AD .DR  .  .ARr.A  . 

1C  .  :N''-.ADDR  .  AREA  . 

18  .  IN’-.ADDR.  ARPA. 

26 . IN-ADDR. ARPA. 

22  .  C  .  2 . 10  .  IN-A;1DR  .  ARPA. 
103.0.0.26. IN-ADDR . ARPA . 
17.0.0.10. IN-ADDR . ARPA . 
4.0.10.18.  IN-AJDDR  .  ARPA  . 
10  3.0.3.26.  IN-AJjDR  .  ARPA  . 
6.3.0.10.  IN-?T)DR  .  ARPA  . 
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3.6.  Defining  new  types,  classes,  and  special  namespaces 

The  previously  defined  types  and  classes  are  the  ones  in  use  as  of  the 
date  of  this  memo.  New  definitions  should  be  expected.  This  section 
.makes  some  recommendations  to  designers  considering  additions  to  the 
existing  facilities.  The  m.ailing  list  NAI'1EDROPPERS@  SRI -NIC  .  Ai<?A  is  the 
forum  where  general  discussion  of  design  issues  takes  place. 

In  general,  a  new  type  is  appropriate  when  new  information  is  to  be 
added  to  the  database  about  an  existing  object,  or  we  need  new  data 
formats  for  some  totally  new  object.  Designers  should  attempt  to  define 
types  and  their  RDATA  formats  that  are  generally  applicable  to  all 
classes,  and  which  avoid  duplication  of  information.  New  classes  are 
appropriate  when  the  DNS  is  to  be  used  for  a  new  protocol,  etc  which 
requires  new  class-specific  data  formats,  or  when  a  copy  of  the  existing 
name  space  is  desired,  but  a  separate  management  domain  is  necessary. 

New  types  and  classes  need  mnemonics  for  master  files;  the  format  of  the 
master  files  requires  that  the  mnemonics  for  type  and  class  be  disjoint. 

TYPE  and  CLASS  values  must  be  a  proper  subset  of  QTYPEs  and  QCLASSes 
respectively . 

The  present  system  uses  multiple  RRs  to  represent  multiple  values  of  a 
type  rather  than  storing  multiple  values  in  the  RDATA  section  of  a 
single  RR .  This  is  less  efficient  for  most  applications,  but  does  keep 
-R.Rs  shorter.  The  multiple  RRs  assumption  is  incorporated  in  some 
experimental  work  on  dynamic  update  methods. 

The  present  system  attempts  to  minimize  the  duplication  of  data  in  the 
database  in  order  to  insure  consistency.  Thus,  in  order  to  find  the 
address  of  the  host  for  a  mail  exchange,  you  map  the  mail  domain  name  to 
a  host  name,  then  the  host  name  to  addresses,  rather  than  a  direct 
mapping  to  host  address .  This  approach  is  preferred  because  it  avoids 
the  opportunity  for  inconsistency. 

In  defining  a  new  type  of  data,  multiple  RR  types  should  not  be  used  to 
create  an  ordering  between  entries  or  express  different  formats  for 
equivalent  bindings,  instead  this  information  should  be  carried  in  the 
body  of  the  RR  and  a  single  type  used.  This  policy  avoids  problems  with 
caching  multiple  types  and  defining  QTYDEs  to  matc.h  multiple  types. 

For  example,  the  original  form  of  mail  exchange  binding  used  two  RR 
types  one  to  represent  a  "closer"  exchange  (MD)  and  one  to  represent  a 
"less  close"  exchange  (MF) .  The  difficulty  is  that  the  presence  of  one 
RR  type  in  a  cache  doesn't  convey  any  information  about  the  other 
because  the  query  which  acquired  the  cached  information  might  have  used 
a  QTYPE  of  MF,  MD,  or  MAILA  (which  matched  both) .  The  redesigned 


Mockapet  r is 


[Page  24] 


4-90 


Domain  Names  -  Implementation  and  Specification 


RFC  1035 


RFC  1035  Domain  Implementation  and  Specification  November  1987 


service  used  a  single  type  (MX)  with  a  "pref erence"  value  in  the  RDATA 
section  which  can  order  different  RRs .  However,  if  any  MX  RRs  are  found 
in  the  cache,  then  all  should  be  there. 

4 .  MESSAGES 

4.1.  Fo  rmat 


1  cormunicat ions  inside 
rmiat  called  a  message, 
to  5  sections  (some  of 

of  the  domain  protocol  are  carried  in  a  single 
The  top  level  format  of  message  is  divided 
which  are  empty  in  certain  cases)  shown  below; 

! 

Header 

1 

! 

Question 

Answer 

!  the  question  for  the  name  server 
-  + 

1  RRs  a.nswering  the  question 

i 

Authority 

i  RRs  pointing  toward  an  authority 

1 

-f-- 

Add' t iona 1 

1  RRs  holding  additional  information 
-  +• 

The  header  section  is  always  present.  The  header  includes  fields  th=t 
specify  which  of  the  remaining  sections  are  present,  and  also  specify 
whet.her  the  message  is  a  query  or  a  response,  a  standard  query  or  some 
otter  opcode,-  etc. 

The  names  of  the  sections  after  the  header  are  derived  from  their  use  in 
standard  queries.  The  question  section  contains  fields  that  describe  a 
question  to  a  name  server.  These  fields  are  a  query  type  (QTYPE) ,  a 
query  class  (QCLASS) ,  and  a  query  domain  name  (QNAME) .  The  last  three 
sections  have  the  same  format:  a  possibly  empty  list  of  concatenated 
resource  records  (RRs) .  The  answer  section  contains  RRs  that  answer  the 
question;  Che  authority  section  contains  RRs  that  point  toward  an 
authoritative  name  server;  the  additional  records  section  contains  RRs 
which  relate  to  the  query,  but  are  not  strictly  answers  for  the 
quest  ion  . 
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4.1.1.  Header  section  format 

The  header  contains  the  following  fields; 

111111 

0123456789012345 

+  --  +  ---I---  +  --  +  --  +  --  +  --  +  --  +  --  +  --  +  --+--  +  --+--  +  --  +  --  + 

i  ID  I 

t - + - ^ - 1 - h - 1 - h - 1 - ^ - 1 - ( - H - 1 - 1 - H - j - 1- 

IQR!  Opcode  I AA 1 TC I RD | RA I  Z  I  RCODE  I 

+ - r - 4 - .^ - 1 - 1 - 1 - 1 - - ( - ( - 1 - 1 - 1 - - 1 - f 

i  QDCOUNT  I 

!  ANCOUNT  I 

■f - 1 - - 1 - i - i - H - i - H - ( - 1 - 1 - 1 - J - h - H - -f 

1  NSCOUNT  I 

I  ARCOUNT  I 

+  --  +  --  +  --  +  --1---  +  --  +  --  + - f + 


where  ; 


ID 


QR 


OPCODE 


AA 


A  16  bit  identifier  assigned  by  the  program  that 
generates  any  kind  of  query.  This  identifier  is  copied 
the  corresponding  reply  and  can  be  used  by  the  requester 
to  match  up  replies  to  outstanding  queries. 

2  one  bit  field  that  specifies  whether  this  message  is  a 
query  (0) ,  or  a  response  (1) . 

A  four  bit  field  that  specifies  kind  of  query  in  this 
message.  This  value  is  set  by  the  originator  of  a  query 
and  copied  into  the  response.  The  values  are: 

0  a  standard  query  (QUERY) 

1  an  inverse  query  (IQUERY) 

2  a  server  status  request  (STATUS) 

3-15  reserved  for  future  use 

Authoritative  Answer  -  this  bit  .^s  valid  in  responses, 
and  specifies  that  the  responding  name  server  is  an 
authority  for  the  domain  na-no  in  question  section. 

Note  that  the  contents  of  the  answer  section  may  have 
multiple  owner  names  because  of  aliases.  The  AA  bit 
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TC 

RD 

RA 

2 

RCODE 


Mockapetr is 


corresponds  to  the  name  which  matches  the  query  name,  or 
the  first  owner  name  in  the  answer  section. 

Truncation  -  specifies  that  this  message  was  truncated 
due  to  length  greater  than  that  permitted  on  the 
transmission  channel. 

Recursion  Desired  -  this  bit  may  be  set  in  a  query  and 
is  copied  into  the  response.  If  RD  is  set,  it  directs 
the  namie  server  to  pursue  the  query  recursively. 
Recursive  query  support  is  optional. 

Recursion  Available  -  this  be  is  set  or  cleared  in  a 
response,  and  denotes  whether  recursive  query  support  is 
available  in  the  name  server. 

Reserved  for  future  use.  Must  be  zero  in  all  queries 
and  responses  . 

Response  code  -  this  4  bit  field  is  set  as  part  of 
responses.  The  values  have  the  followir.o 
interpretation: 

0  No  error  condition 

1  Format  error  -  The  name  server  was 
unable  to  interpret  the  query. 

2  Server  failure  -  The  name  server  war 
unable  to  process  this  query  due  to  a 
problem  with  the  name  server. 

3  Name  Error  -  Meaningful  only  for 
responses  from  an  authoritative  name 
server,  this  code  signifies  that  the 
domain  name  referenced  in  the  query  does 
not  exist . 

4  Not  Implemented  -  The  name  server  does 
not  support  the  requested  kind  of  query. 

5  Refuse  -he  name  server  refuses  to 

perforr  specified  operation  for 

policy  reasons .  For  example,  a  name 
server  may  not  wish  to  provide  the 
information  to  the  particular  requester, 
or  a  name  server  may  not  wish  to  perform 
a  particular  operation  (e.g.,  zone 
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QDCOUNT 


ANCOUNT 


NSCOUNT 


6-15 


transfer)  for  particular  data. 
Reserved  for  future  use. 


an  unsigned  16  bit  integer  specifying  the  number  of 
entries  in  the  question  section. 

an  unsigned  lb  bit  integer  specifying  the  number  of 
resource  records  in  the  answer  section. 

an  unsigned  16  bit  integer  specifying  the  number  of  name 
server  resource  records  in  the  authority  records 
section . 


ARCOUNT 


an  unsigned  16  bit  integer  specifying  the  number  of 
resource  records  in  the  additional  records  section. 


4.1.2.  Question  section  format 

The  question  section  is  used  to  carry  the  "question"  in  most  queries, 
i.e.,  the  parameter.,  that  de'^ine  what  is  being  asked.  The  section 
contains  QDCOUNT  (usually  1)  entries,  each  of  the  following  format: 


01234567 


111111 
i  9  0  1  r  3  4  5 

I  I 

/  QNAME  / 

/  / 

— + — + — + — + — 

1  QTYPE  I 

+  +  +  +  +  +  +  +  4 - +  + 

I  QCLASS  I 

— + — + — 


where ; 
QNANE 


QTYPE 


a  domain  name  represented  as  a  sequence  of  labels,  where 
each  label  consists  of  a  length  octet  followed  by  that 
number  of  octets.  The  domain  name  terminates  with  the 
zero  length  octet  for  the  null  label  of  the  root.  Note 
that  this  field  may  be  an  odd  number  of  octets;  no 
padding  is  used. 

a  two  octet  code  which  specifies  the  type  of  the  query. 
The  values  for  this  field  include  all  codes  valid  for  a 
TYPE  field,  together  with  some  more  general  codes  which 
can  match  more  than  one  type  of  RR. 
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QCLASS  a  two  octet  code  that  specifies  the  class  of  the  query. 

For  example,  the  QCLASS  field  is  IN  for  the  Internet. 

4.1  .3.  Res~'''.rce  record  format 

The  answer,  authority,  and  additional  sections  all  share  the  same 
format:  a  variable  number  of  resource  records,  where  the  number  of 
records  is  specified  in  the  corresponding  count  field  in  the  header. 
Each  resource  record  has  the  following  format: 

111111 

0123456789012345 

I  I 

/  / 

/  N.AN.E  / 

I  1 

+  + - +  +  +  +  +  +  +  +  + 

1  TYPE  1 

I  CLASS  I 

1  TTL  I 

I  I 

+  __  +  —  +  +  —  +  --r 4---  +  --  +  —  +  —  +  --  +  —  +  + 

I  RDLENGTH  I 

4 - ( - 4 - 1 - 1 - 1 - 4  -  ■  —  4' - 1 - i - 1 - 1 - 1 - 1 - i - j - I 

/  RDATA  / 

/  / 


where : 

NAME  a  domain  narae  to  which  this  resource  record  pertains. 

TYPE  two  octets  containing  one  of  the  RR  type  codes.  This 

field  specifies  the  meaning  of  the  data  in  the  RDATA 
field . 

CLASS  two  octets  which  specify  the  Class  of  the  data  in  the 

RDATA  field. 

TTL  a  32  bit  unsigned  integer  that  specifies  the  time 

interval  (in  seconds)  that  the  resource  record  may  be 
cached  before  it  should  be  discarded.  Zero  values  are 
interpreted  to  mean  that  the  RR  can  only  be  used  for  the 
transaction  in  progress,  and  should  not  be  cached. 
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RDLENGTH  an  unsigned  16  bit  integer  that  specifics  the  length  in 

octets  of  the  ROATA  field. 

RDATA  a  variable  length  string  of  octets  that  describes  the 

resource.  The  format  of  this  information  varies 
according  to  the  TYPE  and  CLASS  of  the  resource  record. 
For  example,  the  if  the  TYPE  is  A  and  the  CLASS  is  IN, 
the  RDATA  field  is  a  4  octet  ARPA  Internet  address. 

1.1.4.  Message  compression 

In  order  to  reduce  the  size  of  messages,  the  domain  system  utilizes  a 
compression  scheme  which  eliminates  the  repetition  of  domain  names  in  a 
message.  In  this  scheme,  an  entire  domain  name  or  a  list  of  labels  at 
the  end  of  a  domain  name  is  replaced  with  a  pointer  to  a  prior  occurance 
of  the  same  name. 

The  pointer  takes  the  form  of  a  two  octet  sequence: 

II  II  OFFSET  1 

+  +  —  +  —  4.__  +  __  +  __  + 

The  first  two  bits  are  ones.  This  allows  a  pointer  to  be  distinguished 
from  a  label,  since  the  label  must  begin  with  two  zero  bits  because 
labels  are  restricted  to  63  octets  or  less.  (The  10  and  01  combinations 
are  reserved  for  future  use.)  The  OFFSET  field  specifies  an  offset  from 
the  start  of  the  message  (i.e.,  the  first  octet  of  the  ID  field  in  the 
dorriain  header)  .  A  zero  offset  specifies  the  first  byte  of  the  ID  field, 
etc . 

The  compression  scheme  allows  a  aomain  name  in  a  message  to  be 
represented  as  either: 

-  a  sequence  of  labels  ending  in  a  zero  octet 

-  a  pointer 

-  a  seque.nce  of  labels  ending  with  a  pointer 

Pointers  can  only  be  used  for  occurances  of  a  domain  name  where  the 
format  is  not  class  specific.  If  this  were  not  the  case,  a  name  server 
or  resolver  would  be  required  to  know  the  format  of  all  RRs  it  handled. 
As  yet,  there  are  no  such  cases,  but  they  may  occur  in  future  RDATA 
formats . 

If  a  domain  name  is  contained  in  a  part  of  the  message  subject  to  a 
length  field  (such  as  the  RDATA  section  of  an  RR) ,  and  compression  is 
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used,  the  length  of  the  compre'=sed  name  is  used  in  the  length 
calculation,  rather  than  the  length  of  the  expanded  name. 

Programs  are  free  to  avoid  using  pointers  in  messages  they  generate, 
although  this  will  reduce  datagram  capacity,  and  may  cause  truncation. 
However  all  programs  are  required  to  understand  arriving  messages  that 
contain  pointers. 

For  e.xample,  a  datagram  might  need  to  use  the  domain  names  F.ISI.ARPA, 
FOO  .  F  .  IS  I  .  ARPA,  ARPA,  and  the  root.  Ignoring  the  other  fields  of  t.he 
m.essage,  these  domain  names  might  be  represented  as: 

H - 1 - ( - 1 - 1 - K - 1 - 1 - 1 - h - 1 - 1 - 1 - 1 - H - i 1- 

20  I  1  I  F  I 

+  1 - +  + 

22  I  3  I  I  I 

+  + 

24  I  S  1  I  I 

26  1  4  I  A  I 

4 - 1 - 1 - -t - y - h - 1 - H - ( - i - - 1 - 1 - y - 1 - 1-  —  — 1- 

28  I  R  I  P  I 

+  i  __4.__  +  __  +  __  +  __  +  __  +  __  +  __  +  __  + 

30  I  A  I  0  I 

—  —  —  —  - ^ - }. - + 

— +--+ - + - +--+ - +--+ - +--+ 

40  I  3  I  F  I 

+  +  —  +  --  +  —  +  —  + — +  —  + 

42  I  0  1  0  I 

+  +  —  +  --  + 

44  I  1  II  20  I 

+ - +  +  - +  --  + - +  + - + - + - + - + - +  + 

64  I  1  11  26  I 

+  ---1  -  -  +  + - + - + - +  --  + - +  + 

92  I  0  I  i 

+__+_-+__+__+__+__+__+__4 

The  domain  name  for  F.ISI.ARPA  is  shown  at  offset  20.  The  domain  name 
FOO . F . ISI . ARPA  is  shown  at  offset  40;  this  definition  uses  a  pointer  to 
concatenate  a  label  for  FOO  to  the  previously  defined  F.ISI.ARPA.  The 
domain  name  ARPA  is  defined  at  offset  64  using  a  pointer  to  the  ARPA 
component  of  the  nam.e  F.ISI.ARPA  at  20;  note  that  this  pointer  relies  on 
ARPA  being  the  last  label  in  the  string  at  20.  The  root  domain  name  is 
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defined  by  a  single  octet  of  zeros  at  92;  the  root  domain  name  has  no 
labels . 

4.2.  Transpo  rt 

The  DNS  assumes  that  messages  will  be  transmitted  as  datagrams  or  in  a 
byte  stream  carried  by  a  virtual  circuit.  While  virtual  circuits  can  be 
usea  for  any  DNS  activity,  datagrams  are  preferred  for  queries  due  to 
their  lower  overhead  and  better  performance.  Zone  refresh  activities 
must  use  virtual  circuits  because  of  the  need  for  reliable  transfer. 

The  Internet  supports  name  server  access  using  TCP  [RFC-793]  on  server 
port  53  (decimal)  as  well  as  datagram  access  using  UDP  [RFC-768]  on  UDP 
port  53  (decimal) . 

4.2.1.  UDP  usage 

Messages  sent  using  UDP  user  server  port  53  (decimal) . 

Messages  carried  by  UDP  are  restricted  to  512  bytes  (not  counting  the  IP 
or  UDP  headers) .  Longer  messages  are  truncated  and  the  TC  bit  is  set  in 
the  (leader. 

UDP  is  not  acceptable  for  zone  transfers,  but  is  the  recommended  method 
for  standard  queries  in  the  Internet.  Queries  sent  using  UDP  may  be 
lost,  and  hence  a  retransmission  strategy  is  required.  Queries  or  their 
responses  may  be  reordered  by  the  networic,  or  by  processing  in  name 
servers,  so  resolvers  should  not  depend  on  themi  being  returned  in  order. 

The  optimal  UDP  retransmission  policy  will  vary  with  performance  of  the 
Internet  and  the  needs  of  the  client,  but  the  following  are  recommended: 

-  The  client  should  try  other  servers  and  server  addresses 
before  repeating  a  query  to  a  specific  address  of  a  server. 

-  The  retransmission  interval  should  be  based  on  prior 

statistics  if  possible.  Too  aggressive  retransmission  can 
easxjLjf  .i.e3p..,rioev,  i.v^r  t)*c  v.  m  w.^tty  c*"  Depending 

on  hov?  well  connected  the  client  is  to  its  expected  servers, 
the  minimum  retransmission  interval  should  be  2-5  seconds. 

More  suggestions  on  server  selection  and  retransmission  policy  can  be 
found  in  the  resolver  section  of  this  memo. 

4.2.2.  TCP  usage 

Messages  sent  over  TCP  connections  use  server  port  53  (decimal) .  The 
message  is  prefixed  with  a  two  byte  length  field  which  gives  the  message 
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length,  excluding  the  two  byte  length  field.  This  le.ngth  field  allows 
the  low-level  processing  to  assemble  a  cjrr.plete  message  before  begir.r.im 
to  pa  rse  it  . 

Several  connection  management  policies  are  reco.mmen  led : 

-  The  .server  should  net  block  ether  activities  waiting  for  TCP 
data  . 

-  The  server  should  s^ippcrt  rr.ultiple  cc::nect  i  ons  . 

-  The  server  should  assurr.e  that  the  client  v.till  initiate 
connection  closing,  and  should  delay  closing  its  end  of  the 
connection  until  all  outstanding  client  requests  have  teen 
sat  is  f ied . 

-  If  the  server  needs  to  close  a  dormar.t  connection  to  leclaim'. 
resources,  it  .‘=hould  wait  until  the  connect  icn  has  been  idle 
for  a  period  or.  the  order  of  two  minutes.  In  particular,  tr.e 
server  should  allow  the  SOA  and  AXFR  request  sequence  (wnich 
begins  a  refresh  operation)  to  be  made  on  a  single  cc.r.nect  ion  . 

Since  the  server  would  be  unable  to  answer  queries  anyway,  a 
unilateral  close  or  reset  may  be  used  ir..stead  of  a  graceful 
close . 

5.  MASTER  FILES 

Master  files  are  text  files  that  contain  R.Rs  in  text  fo-rm.  Since  the 
contents  of  a  zone  can  be  e.xpressed  in  the  form  of  a  list  of  RRs  a 
iTiaster  file  is  most  often  used  to  defi.ne  a  zone,  though  it  can  be  uso.l 
to  list  a  cache's  contents.  Hence,  this  secticr.  first  discu.sses  the 
format  of  RRs  in  a  master  file,  and  then  tt.e  .special  cons  i  de  rat  i  c s  wh'..:. 
a  master  file  is  used  to  create  a  zone  in  s.:rr.e  name  server. 

5.1.  Format 

The  format  of  these  files  is  a  sequence  of  entries.  Entries  are 
predominantly  line-oriented,  though  parentheses  can  be  used  -u  co.ntinue 
a  list  of  items  across  a  line  boundary,  and  text  literals  can  contain 
CRLF  within  the  text.  Any  corribinat icn  of  tabs  and  spaces  act  as  a 
delimiter  between  the  separate  items  that  make  up  an  entry.  The  end  ■  f 
any  line  in  the  master  file  can  end  with  a  comment.  The  commen*: 
with  a  " ; "  (semicolon) . 

The  following  entries  are  defined: 

<blank:>  [<comment>] 
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$ORIGIN  •  >omain-name>  [<ccmment>] 

.aDE  <file-name>  [<dcm.3in-name>]  [<comiment>j 


<doma  L  n -r 


[  <comment>] 


<r-lar)k><rr>  [<comment>] 

Rlnok  lines,  with  or  withont  comments,  are  allowed  anywhere  in  the  file. 

Two  control  entries  are  defined:  SORIGIN  and  $INCL'JDE.  $ORIGIN  is 
:  il:wed  by  a  domain  name,  and  resets  the  current  origin  for  relative 
i.rt.ain  na.mes  to  trie  stated  name.  $INCLUDE  inserts  the  named  file  into 
'  .to  current  file,  and  m.ay  optionally  specify  a  domain  name  that  sets  the 
relative  domain  na.me  origin  for  the  included  file.  SINCLUDE  may  also 
a  cC'mment.  .Note  that  a  $INCLoDE  entry  never  changes  the  relative 
.7  .  n  cf  the  parent  file,  regardless  of  changes  to  the  relative  origin 
:•  :  :o  wrthin  the  included  file. 


two  fcrm„? 
fj  f;  h  6  r .  P 
r  y  ^  ^  9  3 


represent  .RRs.  If  an  entry  fo 
is  assumei  to  be  owned  by  the 
with  a  <dcma i..-r.a:!ie,»,  tnen  the 


a:'.  RR  begins  with  a 
St  stated  owner.  * 
wn-.;r  na.me  is  re.set  . 


t  aK,  e  one 


the  folio; 


l'TTl>',  l<class>]  <type>  <RDATj^> 
1 '  '  1  a  ,s  s  > '.  i-'TTIC*;  <type>  <RDATA> 


The  P.F  begirus  with  optional  TTL  and  class  fields,  followed  by  a  type  and 
.-CATA  field  appropriate  to  the  type  and  class.  Class  and  type  use  the 
an  da  rd  m.nemonics,  TTL  is  a  deci.mal  integer.  Omitted  class  and  TTL 
val.:e3  are  Jefault  to  the  last  e.xpiicitly  stated  values.  Since  type  and 
class  rrrnerr.onic.s  are  disjoint,  the  parse  is  unique.  (Note  that  this 
..rier  is  different  from  the  order  used  in  e:-:arnples  and  the  Older  used  in 
vice  actual  RRs;  the  given  order  allows  easier  parsing  and  defaulting.) 


'  ;  ma  i  r.-name>3  make  up  a  large  share  of  the  data  in  th.e  master  file. 

Thv;  iabeis  in  the  domain  narr;e  are  expressed  as  character  strings  and 
cn-purated  by  dots.  Quoting  conventions  allow  arbitrary  characters  to  be 
.V.  ,rel  in  domain  names.  Domain  names  that  end  in  a  dot  are  called 
abc  lute,  and  are  taken  as  corr;plete.  Domain  na.mes  which  do  not  end  in  a 
i  t  are  called  relative;  the  actual  domain  nam^e  is  the  c  ncatenation  of 
'he  relative  part  with  an  origin  specified  in  a  SO.RIGTN,  SINCLUDE,  or  as 
an  argument  to  the  master  file  loading  routine.  A  relative  name  is  an 
e.’r;r  whe.o  no  origin  is  available. 
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<chara  .Ler-string>  is  expressed  in  one  or  two  ways;  as  a  contiguons 
of  characters  without  interior  spaces,  or  as  a  string  beginning  with  a  " 
and  ending  with  a  Inside  a  "  delimited  string  any  character  can 

jccur,  excejtt  for  a  "  itself,  which  must  be  quoted  using  \  (back  slash)  . 

Because  tiiese  files  are  text  files  several  special  encooiings  are 
r.eoossary  to  allow  arbitrary  data  to  be  loaded.  Ir;  particular; 

of  the  root. 

h  free  sranri'ng  0  i  .s  used  to  denote  the  current  .rigin. 

where  X  is  any  character  other  than  a  digit  (0-9),  is 
used  to  quote  that  character  so  that  its  sfiecial  mear.ir.o 
does  not  apply.  For  exa.v.ple,  "\."  can  be  used  tc  place 
a  Cot  character  in  a  label. 

where  each  D  is  a  di.git  is  the  octet  correspGi.d;';g  t 
the  decimal  number  described  by  n.OD .  The  resulting 
octet  is  assu.med  to  be  text  and  is  not  checked  for 
special  m.can ing. 

Parentheses  are  used  to  group  data  that  cresses  a  line- 
boundary.  In  effect,  line  terminations  are  net 
recognized  within  parentheses. 

Semicolon  is  used  to  start  a  comraent;  the  remainder  of 
the  line  is  ignored. 

.5.2.  Use  of  m.aster  files  to  define  zones 

When  a  m.aster  file  is  used  to  load  a  zone,  the  operation  should  be 
suppressed  if  any  errors  are  encountered  in  the  master  file.  The 
rationale  for  this  is  that  a  single  error  can  have  widespread 
consequences.  For  example,  suppose  that  the  RRs  defining  a  delegation 
have  syntax  errors;  then  the  server  will  return  authoritative  nam.e 
errors  for  a.ll  names  in  the  subzone  (except  in  the  rase  where  the 
subzone  is  also  present  on  the  server)  . 

Several  other  validity  checks  that  should  be  performied  in  additicn  to 
insuring  that  the  file  is  syntactically  correct; 

1.  All  RRs  in  the  file  should  have  the  same  class. 

2.  Exactly  one  SOA  RR  should  be  present  at  the  top  of  the  zone. 

3.  If  delegations  are  present  and  glue  information  is  required, 
it  should  be  present  . 
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4.  Information  present  our  side  of  the  authoritative  nodes  in  the 
zone  should  be  glue  information,  rather  than  the  result  of  an 
origin  or  similar  error. 

5.3.  -Master  file  example 

The  following  is  an  example  file  wh'''u  might  be  used  to  define  the 
ISI.CDU  zone. and  is  loaded  with  an  origin  or  ISI.EDU; 


@  IN 

SCA 

VENERA  Action\ .domains  ( 

20 

SERIAL 

7200 

REi RESH 

600 

RETRY 

3600000; 

EXPIRE 

60) 

MINIM' 'M 

NS 

A.  ISI .EDU. 

NS 

VENERA 

NS 

VAXA 

MX 

10  VENERA 

MX 

1 0  VAXA 

A 

A 

26.3.0.103 

VENERA 

A 

10.1.0.52 

A 

120.9.0.32 

VAXA 

A 

10.2.0.27 

A 

128.9.0.33 

SINCLUDE  <SUBSYS>ISI-MAILBOXES .TXT 

Where  the  file  <SUBSYS>ISI-MAILBOXES .TXT  is: 


MOE  MB 

LARRY  MB 
CURLEY  MB 
STOOGES  MG 
MG 
MG 


A.  ISI .EDU. 
A.  ISI .EDU. 
A.  ISI .EDU. 
MOE 
LARRY 
CURLEY 


Note  the  use  of  the  \  character  in  the  SOA  RR  to  specify  the  responsible 
person  m.ailbox  "Action  .domains@E  .  ISI  .EDL"  . 
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6.  NAME  SERVER  IMPLEMENTATION 

6.1.  Architecture 

The  optimal  structure  for  the  na.me  server  will  depend  on  the  host 
operating  system  and  whether  the  name  server  is  integrated  with  resolver 
operations,  either  by  supporting  recursive  service,  or  by  sharing  its 
database  with  a  resolver.  This  section  discusses  implementation 
considerations  for  a  name  server  which  shares  a  database  with  a 
resolver,  but  most  of  these  concerns  are  present  in  any  name  server. 

6.1.1.  Control 

A  name  server  must  employ  multiple  concurrent  activities,  whether  they 
are  implemented  as  separate  tasks  in  the  host's  OS  or  multiplexing 
inside  a  single  name  server  program.  It  is  simply  not  acceptable  for  a 
name  server  to  block  the  service  of  UDP  requests  while  it  waits  for  TCP 
data  for  refreshing  or  query  activities.  Similarly,  a  name  server 
should  not  attempt  to  provide  recursive  service  without  processing  such 
requests  in  parallel,  though  it  may  choose  to  serialize  requests  from  a 
single  client,  or  to  regard  identical  requests  from  the  same  client  as 
duplicates.  A  name  server  should  not  substantially  delay  requests  while 
it  reloads  a  zone  from  master  files  or  while  it  incorporates  a  newly 
refreshed  zone  into  its  database. 

6.1.2.  Database 

While  name  server  implementations  are  free  to  use  any  internal  data 
structures  they  choose,  the  suggested  structure  consists  of  three  major 
parts  : 


-  A  "catalog"  data  structure  which  lists  the  zones  available  to 
this  server,  and  a  "pointer"  to  the  zone  data  structure.  The 
main  purpose  of  this  structure  is  to  find  the  nearest  ancestor 
zone,  if  any,  for  arriving  standard  queries. 

-  Separate  data  structures  for  each  of  the  zones  held  by  the 
name  server. 

-  A  data  structure  for  cached  data,  (or  perhaps  separate  caches 
for  different  classes) 

All  of  these  data  structures  can  be  implemented  an  identical  tree 
structure  format,  with  different  data  chained  off  the  nodes  in  different 
parts;  in  the  catalog  the  data  is  pointers  to  zones,  while  in  the  zone 
and  cache  data  structures,  the  data  will  be  RRs .  In  designing  the  tree 
framewr)rk  the  designer  should  recognize  that  query  processing  will  need 
to  traverse  the  tree  using  case-insensitive  label  comparisons;  and  that 
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in  real  data,  a  few  nodes  have  a  very  high  branching  factor  (100-1000  or 
more),  but  the  vast  majority  have  a  very  low  branching  factor  (0-1)  . 

One  way  to  solve  the  case  problem  is  to  store  the  labels  for  each  node 
in  two  pieces:  a  standardized-case  representation  of  the  label  where  all 
ASCII  characters  are  in  a  single  case,  together  with  a  bit  mask  that 
denotes  which  characters  are  actually  of  a  different  case.  The 
branching  factor  diversity  can  be  handled  using  a  simple  linked  list  for 
a  node  until  the  branching  factor  exceeds  some  threshold,  and 
transitioning  to  a  hash  structure  after  the  threshold  is  exceeded.  In 
any  case,  hash  structures  used  to  store  tree  sections  must  insure  that 
hash  functions  and  procedures  preserve  the  casing  conventions  of  the 
DNS  . 

The  use  of  separate  structures  for  the  different  parts  of  the  database 
is  motivated  by  several  factors: 

-  The  catalog  structure  can  be  an  almost  static  structure  that 
need  change  only  when  the  system  administrator  changes  the 
zones  supported  by  the  server.  This  structure  can  also  be 
used  to  store  parameters  used  to  control  refreshing 
activities . 

-  The  individual  data  structures  for  zones  allow  a  zone  to  be 
replaced  simply  by  changing  a  pointer  in  the  catalog.  Zone 
refresh  operations  can  build  a  new  structure  and,  when 
complete,  splice  it  into  the  database  via  a  simple  pointer 
replacement .  It  is  very  important  that  when  a  zone  is 
refreshed,  queries  should  not  use  old  and  new  data 
simultaneously . 

-  With  the  proper  search  procedures,  authoritative  data  in  zones 
will  always  "hide",  and  hence  take  precedence  over,  cached 
data . 

-  Errors  in  zone  definitions  that  cause  overlapping  zones,  etc., 
may  cause  erroneous  responses  to  queries,  but  problem 
determination  is  simplified,  and  the  contents  of  one  "bad" 
zone  can't  corrupt  another. 

-  Since  the  cache  is  most  frequently  updated,  it  is  most 
vulnerable  to  corruption  during  system  restarts.  It  can  also 
become  full  of  expired  RR  data.  In  either  case,  it  can  easily 
be  discarded  without  disturbing  zone  data. 

A  major  aspect  of  database  design  is  selecting  a  structure  which  allows 
the  name  server  to  deal  with  crashes  of  the  name  server's  host.  State 
information  which  a  name  server  should  save  across  system  crashes 
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includes  the  catalog  structure  (including  the  state  of  refreshing  for 
each  zone)  and  the  zone  data  itself. 

6.1.3.  T ime 

Both  the  TTL  data  for  RRs  and  the  timing  data  for  refreshiig  activities 
depends  on  32  bit  ti.mers  in  units  of  second.s  .  Inside  the  database, 
refresh  timers  and  TTLs  for  cached  data  conceptually  "count  dow.n",  v.-hile 
data  in  the  zone  stays  with  constant  TTLs. 

A  recommended  implementation  strategy  is  to  store  time  in  two  ways:  as 
a  relative  increment  and  as  an  absolute  time.  One  way  to  do  this  is  to 
use  positive  32  bit  numbers  for  one  type  and  negative  numbers  for  the 
other.  The  RRs  in  zones  use  relative  times;  the  refresh  timers  and 
cache  data  use  absolute  times.  Absolute  numbers  are  taken  with  respect 
to  some  known  origin  and  converted  to  relative  values  when  placed  in  the 
response  to  a  query.  When  an  absolute  TTL  is  negative  after  conversion 
to  relative,  then  the  data  is  expired  and  should  be  ignored. 

6.2.  Standard  query  processing 

The  major  algorithm  for  standard  query  processing  is  presented  in 
[RFC-1034] . 

When  processing  queries  with  QCLASS=*,  or  some  other  QCLASS  which 
matches  multiple  classes,  the  response  should  never  be  authoritative 
unless  the  server  can  guarantee  that  the  response  covers  all  classes. 

When  composing  a  response,  RRs  which  are  to  be  inserted  in  the 
additional  section,  but  duplicate  RRs  in  the  answer  or  authority 
sections,  may  be  omitted  from  the  additional  section. 

When  a  response  is  so  long  that  truncation  is  required,  the  truncation 
should  start  at  the  end  of  the  response  and  work  forward  in  the 
datagram.  Thus  if  there  is  any  data  for  the  authority  section,  the 
answer  section  is  guaranteed  to  be  unique. 

The  MINIMUM  value  in  the  SOA  should  be  used  to  set  a  floor  on  the  TTL  of 
data  distributed  from  a  zone.  This  floor  function  should  be  done  when 
the  data  is  copied  into  a  response.  This  will  allow  future  dynamic 
update  protocols  to  change  the  SOA  MINIMUM  field  without  ambiguous 
semantics . 

6.3.  Zone  refresh  and  reload  processing 

In  spite  of  a  server's  best  efforts,  it  may  be  unable  to  load  zone  data 
from  a  master  file  due  to  syntax  errors,  etc.,  or  be  unable  to  refresh  a 
zone  within  the  its  expiration  parameter.  In  this  case,  the  name  server 
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should  answer  queries  as  if  it  were  not  supposed  to  possess  the  zone. 

If  a  master  is  sending  a.  zone  out  via  AXFR,  and  a  new  version  is  created 
during  the  transfer,  the  master  should  continue  to  send  the  old  version 
if  possible.  In  any  case,  it  should  never  send  part  of  one  version  and 
part  of  another.  If  completion  is  not  possible,  tne  master  should  reset 
t.he  Go.nnection  on  which  the  zone  transfer  is  taking  place. 

6.4.  Inverse  queries  (Optional) 

Inverse  queries  are  an  optional  part  of  the  DNS.  Name  servers  are  not 
ret’uired  to  support  any  f.^'r.m  cf  inverse  queries.  If  a  name  server 
receives  an  inverse  query  tnat  it  does  not  support,  it  returns  an  error 
respo.n.se  with  the  "Not  Irtplertiented"  error  set  in  the  header.  While 
inverse  query  support  is  optional,  all  name  servers  .must  be  at  least 
able  to  return  the  error  response. 

6.4.1.  The  contents  of  i.nverse  queries  and  responses  Inverse 

q:erie3  reverse  t.ie  mappi.ngs  performed  by  standard  query  operations; 
while  a  standard  query  maps  a  domain  name  to  a  resource,  an  inverse 
query  maps  a  resource  to  a  domain  narrie .  For  exam.ple,  a  standard  query 
m.ight  bind  a  domain  name  to  a  host  address;  the  corresponding  inverse 
query  binds  the  host  address  to  a  domain  name. 

Inverse  queries  take  the  form  of  a  single  RR  in  the  answer  section  of 
the  fiessage,  with  an  empty  question  section.  The  owner  name  of  the 
query  R.R  and  its  TTL  are  not  significant.  The  response  carries 
questions  in  the  question  section  which  identify  all  names  possessing 
the  query  RR  V.’HICH  THF  t-fr'-KE  SERVER  KNOWS.  Since  no  name  server  knows 
about  all  of  the  domain  name  space,  the  response  can  never  be  assumed  to 
be  complete.  Thus  inverse  queries  are  primarily  useful  for  database 
management  and  debugging  activities.  Inverse  queries  are  NOT  an 
acceptable  miethod  of  mapping  host  addresses  to  host  names;  use  the  IN- 
r>IlDR.ARPA  domain  instead. 

Where  possible,  namie  servers  should  provide  case-insensitive  comparisons 
for  inverse  queries.  Thus  an  inverse  query  asking  for  an  MX  RR  of 
"Venera.isi.edu"  should  get  the  same  response  as  a  query  for 
"VENERA.ISI.EDU";  an  inverse  query  for  HINFO  RR  "IBM-PC  UNIX"  should 
produce  the  same  result  as  an  inverse  query  for  "IBM-pc  unix".  However, 
this  cannot  be  guaranteed  because  name  servers  may  possess  RRs  that 
contain  character  strings  but  the  name  server  does  not  know  that  the 
data  is  character. 

When  a  name  server  processes  an  inverse  query,  it  either  returns; 

1 .  zero,  one,  or  multiple  domain  names  for  the  specified 
resource  as  QNAMEs  in  the  question  section 
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2.  an  error  code  indicating  that  the  name  server  doesn't  support 
inverse  mapping  of  the  specified  resource  type. 

When  the  response  to  an  inverse  query  contains  one  or  more  QNAMEs,  the 
owner  name  and  TTL  of  the  RR  in  the  answer  section  which  defines  the 
inverse  query  is  modified  to  exactly  match  an  RR  found  at  the  first 
CNAME . 

RRs  returned  in  the  inverse  queries  cannot  be  cached  using  the  same 
mechanism  as  is  used  for  the  replies  to  standard  queries.  One  reason 
■*"or  this  is  that  a  name  might  have  multiple  RRs  of  the  same  type,  and 
only  one  would  appear.  For  example,  an  inverse  query  for  a  single 
address  of  a  multiply  homed  host  might  create  the  impression  that  only 
one  address  existed. 

6.4.2.  Inverse  query  and  response  example  The  overall  structure 

of  an  inverse  query  for  retrieving  the  domain  name  that  corresponds  to 
Internet  address  10.1.0.52  is  shown  below: 


H - H 

Header  I  OPCODE=IQUERY,  ID=997  I 

+ - + 

Question  I  <empty>  I 

H - y 

Answer  I  <anyname>  A  IN  10.1.0.52  I 

H - h 

Authority  1  <empty>  I 

^ - (. 

Additional  I  <empty>  I 

+ - + 


This  query  asks  for  a  question  whose  answer  is  the  Internet  style 
address  10.1.0.52.  Since  the  owner  name  is  not  known,  any  domain  name 
can  be  used  as  a  placeholder  (and  is  ignored) .  A  single  octet  of  zero, 
signifying  the  root,  is  usually  used  because  it  minimizes  the  length  of 
the  message.  The  TTL  of  the  RR  is  not  significant.  The  response  to 
this  query  might  be: 
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Header 

1  OPCODE=RESPONSE, 

ID=997 

Question 

|QTYPE=A,  QCLASS=IN,  QNAME^ 

=VENERA. ISI .EDU 

Answer 

1  VENERA.ISI.EDU  A  IN  10 

1.0.52 

Authority 

1  <empty> 

Additional 

1  <empty> 

Note  that  the  QTYPE  in  a  response  to  an  inverse  query  is  the  same  as  the 
TYPE  field  in  the  answer  section  of  the  inverse  query.  Responses  to 
inverse  queries  may  contain  multiple  questions  when  the  inverse  is  not 
unique.  If  the  question  section  in  the  response  is  not  empty,  then  the 
RR  in  the  answer  section  is  modified  to  correspond  to  be  an  exact  copy 
of  an  RR  at  the  first  QNAME . 

6.4.3.  Inverse  query  processing 

■Name  servers  that  support  inverse  queries  can  support  these  operations 
.,hrough  exhaustive  searches  of  their  databases,  but  this  becomes 
■  -ractical  as  the  size  of  the  database  increases.  An  alternative 
u.  ;  roach  is  to  invert  the  database  according  to  the  search  key. 

For  name  servers  that  support  multiple  zones  and  a  large  amount  of  data, 
the  recommended  approach  is  separate  inversions  for  each  zone.  When  a 
particular  zone  is  changed  during  a  refresh,  only  its  inversions  need  to 
be  redone . 

Support  for  transfer  of  this  type  of  inversion  may  be  included  in  future 
versions  of  the  domain  system,  but  is  not  supported  in  this  version. 

6.5.  Completion  queries  and  responses 

The  optional  completion  services  described  in  RFC-882  and  RFC-883  have 
been  deleted.  Redesigned  services  may  become  available  in  the  future. 
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1^  .  RESOLVER  IMPLEMENTATION 

The  top  levels  of  the  recommended  resolver  algorithm  are  discussed  in 
lRFC-1034]  .  This  section  discusses  irr;plementat  ion  details  assuming  the 
database  str"otu£e  suggested  in  the  nairi<a  server  implemciitat ion  section 
of  this  memo. 

7.1.  Trans  fcrrr.ing  a  user  request  into  a  query 

T.he  first  step  a  resolver  takes  is  to  transfor.m  rhe  client's  request, 
stated  in  a  format  suitable  to  the  local  OS,  into  a  search  speci^^ication 
for  .R.Rs  at  a  specific  name  which  match  a  specific  QTYPE  and  QCLASS  . 

Where  possible,  the  QTYPE  and  QCLASS  should  correspond  to  a  single  type 
and  a  single  class,  because  this  makes  the  use  of  cached  data  much 
simpler.  The  reason  for  this  is  that  the  presence  of  data  of  one  type 
i.n  a  cache  doesn't  confirm  the  existence  or  non-existence  of  data  of 
other  types,  hence  the  only  way  to  be  sure  is  to  consult  an 
authoritative  source.  If  QCLASS  =  *  is  used,  the.n  authoritative  answers 
won't  be  available. 

Since  a  resolver  must  be  able  to  multiplex  m.ultiple  requests  if  it  is  to 
perform  its  function  efficiently,  each  pending  request  is  usually 
represented  in  some  block  of  state  information.  This  state  block  will 
typically  contain: 

-  A  timestamp  indicating  the  time  the  request  began. 

The  timestamp  is  used  to  decide  whether  RRs  in  the  database 
can  be  used  or  arc  out  of  -^.ate.  This  timiestamp  uses  the 
absolute  time  format  previously  discussed  for  RR  storage  in 
zones  and  caches .  Note  that  when  an  RRs  TTL  indicates  a 
relative  time,  the  RR  must  be  timely,  since  it  is  part  of  a 
zone.  When  the  RR  has  an  absolute  time,  it  is  part  of  a 
cache,  and  the  TTL  of  the  RR  is  compared  against  the  timestamp 
for  the  start  of  the  request. 

Note  that  using  the  timestamp  is  superior  to  using  a  current 
time,  since  it  allows  RRs  with  TTLs  of  zero  to  be  entered  in 
the  cache  in  the  usual  manner,  but  still  used  by  the  current 
request,  even  after  intervals  of  many  seconds  due  to  system 
load,  query  retransmission  timeouts,  etc. 

-  Some  sort  of  parameters  to  limit  the  amount  of  work  which  will 
be  performed  for  this  request. 

The  amount  of  work  which  a  resolver  will  do  in  response  to  a 
client  request  must  be  limited  to  guard  against  errors  in  the 
database,  such  as  circular  CNAME  references,  and  operational 
problems,  such  as  network  partition  which  prevents  the 


Mockapetris  [Page  43] 


4-109 


INTERNET  PROTOCOL  HANDBOOK  ■  Volume  Four 


1989 


RFC  1035  Domain  Implementation  and  Specification  November  1987 


resolver  from  accessing  the  name  servers  it  needs.  While 
local  limits  on  the  number  of  times  a  resolver  will  retransmit 
a  particular  query  to  a  particular  name  server  address  are 
essential,  the  resolver  should  have  a  global  per-request 
counter  to  limit  work  on  a  single  request.  The  counter  should 
be  set  to  some  initial  value  and  decremented  whenever  the 
resolver  performs  any  action  (retransmission  timeout, 
retransmission,  etc.)  If  the  counter  passes  zero,  the  request 
is  terminated  with  a  temporary  error. 

Note  that  if  the  resolver  structure  allows  one  request  to 
start  others  in  parallel,  such  as  when  the  need  to  access  a 
name  server  for  one  request  causes  a  parallel  resolve  for  the 
name  server's  addresses,  the  spawned  request  should  be  started 
with  a  lower  counter.  This  prevents  circular  references  in 
the  database  from  starting  a  chain  reaction  of  resolver 
activity . 

-  The  SLIST  data  structure  discussed  in  [RFC-1034] . 

This  structure  keeps  track  of  the  state  of  a  request  if  it 
must  wait  for  answers  from  foreign  name  servers. 

Sending  the  queries 

.escribed  in  [RFC-1034],  the  basic  task  of  the  resolver  is  to 
I'rmulate  a  query  which  will  answer  the  client's  request  and  direct  that 
query  to  name  servers  which  can  provide  the  information.  The  resolver 
will  usually  only  have  very  strong  hints  about  which  servers  to  ask,  in 
the  form  of  NS  RRs,  and  may  have  to  revise  the  query,  in  response  to 
C.NAMEs,  or  revise  the  set  of  name  servers  the  resolver  is  asking,  in 
response  to  delegation  responses  which  point  the  resolver  to  name 
servers  closer  to  the  desired  information.  In  addition  to  the 
information  requested  by  the  client,  the  resolver  may  have  to  call  upon 
its  own  services  to  determine  the  address  of  name  servers  it  wishes  to 
contact . 

In  any  case,  the  model  used  in  this  memo  assumes  that  the  resolver  is 
multiplexing  attention  between  multiple  requests,  some  from  the  client, 
and  some  internally  generated.  Each  request  is  represented  by  some 
state  information,  and  the  desired  behavior  is  that  the  resolver 
transmit  aueries  to  name  servers  in  a  way  that  maximizes  the  probability 
that  the  request  is  answered,  minimizes  the  time  that  the  request  takes, 
and  avoids  excessive  transmissions.  The  key  algorithm  uses  the  state 
information  of  the  request  to  select  the  next  name  server  address  to 
query,  and  also  computes  a  timeout  which  will  cause  the  next  action 
should  a  response  not  arrive.  The  next  action  will  usually  be  a 
transmission  to  some  other  server,  but  may  be  a  temporary  error  to  the 
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client  . 

The  resolver  always  starts  with  a  list  of  server  names  to  query  (SLIST) . 
This  list  will  be  all  NS  RRs  which  correspond  to  the  nearest  ancestor 
zone  that  the  resolver  knows  about.  To  avoid  startup  problems,  the 
resolver  should  have  a  set  of  default  servers  which  it  will  ask  should 
it  have  no  current  NS  RRs  which  are  appropriate.  The  resolver  then  adds 
to  SLIST  all  of  the  known  addresses  for  the  name  servers,  and  may  start 
parallel  requests  to  acquire  the  addresses  of  the  servers  when  the 
resolver  has  the  name,  but  no  addresses,  for  the  name  servers. 

To  ccrr.plete  initialization  of  SLIST,  the  resolver  attaches  whatever 
history  information  it  has  to  the  each  address  in  SLIST.  This  will 
usually  consist  of  som.e  sort  of  weighted  averages  for  the  response  time 
of  _he  address,  and  the  batting  average  of  the  address  (i.e.,  how  often 
the  address  responded  at  all  to  the  request) .  Note  that  this 
informLation  should  be  kept  on  a  per  address  basis,  rather  than  on  a  per 
name  server  basis,  because  the  ■^espense  tim.e  and  batting  average  of  a 
particular  server  may  vary  considerably  from  address  to  address.  Note 
also  that  this  information  is  actually  specific  to  a  resolver  address  / 
server  address  pair,  so  a  resolver  with  multiple  addresses  may  wish  to 
keep  separate  histories  for  each  of  its  addresses.  Part  of  this  step 
must  deal  with  addresses  which  have  no  such  history;  in  this  case  an 
expected  round  trip  time  of  5-10  seconds  should  be  the  worst  case,  with 
lower  estimates  for  the  same  local  network,  etc. 

Note  that  whenever  a  delegation  is  followed,  the  resolver  algorithm 
reinitializes  SLIST. 

The  information  establishes  a  partial  ranking  of  the  available  name 
server  addresses.  Each  time  an  address  is  chosen  and  the  state  should 
be  altered  to  prevent  its  selection  again  until  all  other  addresses  have 
been  tried.  The  timeout  for  each  transmission  should  be  50-100%  greater 
than  the  average  predicted  value  to  allow  for  variance  in  response. 

Some  fine  points: 

-  The  resolver  may  encounter  a  situation  where  no  addresses  are 
available  for  any  of  the  name  servers  named  in  SLIST,  and 
where  the  servers  in  the  list  are  precisely  those  which  would 
normally  be  used  to  look  up  their  own  addresses.  This 
situation  typically  occurs  when  the  glue  address  RRs  have  a 
smaller  TTL  than  the  NS  RRs  marking  delegation,  or  when  the 
resolver  caches  the  result  of  a  NS  search.  The  resolver 
should  detect  this  condition  and  restart  the  search  at  the 
next  ancestor  zone,  or  alternatively  at  the  root. 
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-  If  a  resolver  gets  a  server  error  or  other  bizarre  response 
from  a  name  server,  it  should  remove  it  from  snlST,  and  may 
wish  to  schedule  an  immediate  transmission  to  the  next 
candidate  server  address. 

7.3.  Processing  responses 

The  first  step  in  processing  arriving  response  datagrams  is  to  parse  the 
response.  This  procedure  should  include: 

-  Check  the  header  for  reasonableness.  Discard  datagrams  which 
are  queries  when  responses  are  expected. 

-  Parse  the  sections  of  the  message,  and  insure  that  all  RRs  are 
correctly  formatted. 

-  As  an  optional  step,  check  the  TTLs  of  arriving  data  looking 
for  RRs  with  excessively  long  TTLs.  If  a  RR  has  an 
excessively  long  TTL,  say  greater  than  1  week,  eiuher  discard 
the  whole  response,  or  limit  all  TTLs  in  the  response  to  1 
week . 

The  next  step  is  to  match  the  response  to  a  current  resolver  request . 

The  recommended  strategy  is  to  do  a  preliminary  matching  using  the  ID 
field  in  the  domain  header,  and  then  to  verify  that  the  question  section 
corresponds  to  the  information  currently  desired.  This  requires  that 
the  transmission  algorithm  devote  several  bits  of  the  domain  ID  field  to 
a  request  identifier  of  some  sort.  This  step  has  several  fine  points; 

-  Some  name  servers  send  their  responses  from  different 
addresses  than  the  one  used  to  receive  the  query.  That  is,  a 
resolver  cannot  rely  that  a  response  will  come  from  the  same 
address  which  it  sent  the  corresponding  query  to.  This  name 
server  bug  is  typically  encountered  in  UNIX  systems. 

-  If  the  resolver  retransmits  a  particular  request  to  a  name 
server  it  should  be  able  to  use  a  response  from  any  of  the 
transmissions.  However,  if  it  is  using  the  response  to  sample 
the  round  trip  time  to  access  the  name  server,  it  must  be  able 
to  determine  which  transmission  matches  the  response  (and  keep 
transmission  times  for  each  outgoing  message) ,  or  only 
calculate  round  trip  times  based  on  initial  transmissions. 

-  A  name  server  will  occasionally  not  have  a  current  copy  of  a 
zone  which  it  should  have  according  to  some  NS  RRs.  The 
resolver  should  simply  remove  the  name  server  from  the  current 
SLIST,  and  continue. 
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7.4.  Using  the  cache 

In  general,  we  expect  a  resolver  to  cache  all  data  which  it  receives  in 
responses  since  it  may  be  useful  in  answering  future  client  requests. 
However,  there  are  several  types  of  data  which  should  not  be  cached: 

-  When  several  RRs  of  the  same  type  are  available  for  a 
particular  owner  name,  the  resolver  should  either  cache  them 
all  or  none  at  all.  When  a  response  is  truncated,  and  a 
resolver  doesn't  know  whether  it  has  a  com;plete  set,  it  should 
not  cache  a  possibly  partial  set  of  RRs. 

-  Cached  data  should  never  be  used  in  preference  to 
auohoritative  data,  so  if  caching  would  cause  this  to  happen 
the  data  should  nor.  be  cached. 

-  The  results  of  an  ir.vei.se  query  should  net  be  cached. 

-  The  results  of  sta.ndard  queries  where  the  QNAME  contains 
labels  if  the  data  rrdqht  be  used  to  construct  wildcards.  The 
reas-'n  is  that  the  cache;  dees  not  necessarily  contain  existing 
RRs  or  zone  boundary  information  which  is  necessary  to 
restrict  the  app.i.  icot  icr.  of  the  wildcard  P.P.s . 

-  RR  data  in  responses  of  dubiou.s  reliability.  W.hen  a  resolver 
receives  unsolicited  resp.:-nses  or  RR  data  ether  than  that 
reque;5te':,  it  should  discard  it  without  caching  it.  The  basic 
implication  is  that  all  sanity  checks  on  a  p-acket  should  be 
perfcrrr.ed  lefore  any  f  it  is  cached. 

In  a  sirrrlar  vein,  when  a  resolver  has  a  set  of  R.Rs  for  some  name  in  a 
respon.se,  and  wants  to  cache  the  RRs,  it  should  check  its  cache  for 
already  existing  RRs.  Depending  on  the  circumstances,  either  the  data 
in  the  response  or  the  cache  is  preferred,  but  the  two  should  never  be 
combined.  If  the  data  in  the  response  is  from  authoritative  data  in  tt;e 
answer  section,  it  is  always  preferred. 

8.  .MAIL  SUPPORT 

The  dorriain  system  defines  a  standard  for  m;apping  mailboxes  into  domain 
namies,  and  two  methods  for  using  the  mailbox  information  to  derive  mail 
routing  i.nf  ormat  ion .  The  first  meth-^d  is  called  mail  exchange  binding 
and  the  other  m.ethod  is  mailbox  binding.  The  mailbox  encoding  standard 
and  .mail  exchange  binding  are  part  of  the  DNS  official  protocol,  and  are 
the  recommended  miethod  for  mail  routing  in  the  Internet.  Mailbox 
binding  is  an  exper im.enta  1  feature  which  is  still  under  development  and 
subject  to  change. 
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The  ir.ailbox  encoding  standard  assumes  a  mailbox  narrie  of  the  form 
" < 1  oca  1 -pa r t >3 <ma i 1 -domain>" .  While  the  syntax  allowed  in  each  of  these 
sections  varies  substantially  between  the  various  mail  internets,  the 
preferred  syntax  for  the  ARPA  Internet  is  given  in  [RFC-822] . 

The  DNS  encodes  the  <local-part>  as  a  single  label,  and  encodes  the 
<ma  i  1 -dorr.a  in>  as  a  domain  name.  The  single  label  from  t.he  <local-part> 
rs  prefaced  to  the  domain  name  from  <ma i l-domain>  to  form  the  domain 
r.arr.e  c  o  r  r  e  spending  to  the  mailbox.  Thus  the  m.ailbox  KOSTMASTERQ  SRI - 
'.'IS. .ARPA  is  .mapped  i.nto  the  dornain  .name  .HOSTy.ASTER .  SRI -NIC  .  .ARP  A  .  If  the 

<  1  ::ca  1-pa  rt  >  contains  dot.s  or  other  special  characters,  its 
representation  in  a  master  file  will  require  t.he  use  of  backsla.s.h 
quoting  to  e.n.sure  that  the  domain  name  is  properly  encoded.  For 
example,  the  m.ailbox  Act  ion  .  i.xoair.ss  IS  I  .  F.D'j  wauld  be  represented  as 

^.1.  hail  exchange  binding 

exchange  binair.g  uses  the  <.m,ail-dom.aip.>  part  of  a  m.ailbo.x 
float  i’:n  to  determine  where  m.ail  should  be  sent.  The  <local-part> 
t  even  consulted.  [RFC-974j  specifies  this  method  in  detail,  and 
d  be  consulted  before  attempting  to  use  mail  exchange  support. 

of  :  he  advantages  of  this  method  is  that  it  decouples  mail 
;•  •  mat  ion  na.ming  from  the  hosts  used  to  support  mail  service,  at  the 

•  of  another  layer  of  indirection  in  the  lookup  function.  However, 

•.  ne  a  iiition  layer  should  eliminate  the  need  for  complicated  ”!", 

e'  0  eno:  lings  in  < loca 1 -pa rt > . 

I'no  oo.oer.ee  of  the  method  is  that  the  <ma i  1 -doma ir.>  is  used  as  a  domain 
r.a;'v  tv  locate  type  MX  KRc  which  list  hosts  willing  to  accept  mail  for 
.T..a  i  1 -:i  o.ma  in>,  together  with  preference  values  which  rank  the  hosts 
aooorii.ng  to  an  order  specified  by  the  administrators  for  <mail-domain> . 

In  this  mom.o,  the  <ma i  1 -doma in>  ISI.EDU  is  used  in  exaitples,  together 
with  the  hvsts  VE^.’ERA .  IS  I  .  EDU  and  VAXA.ISI.EDU  as  mail  exchanges  for 
ISl.FDV.  If  a  .mailer  had  a  .message  for  Mockapetris3lSI.EDU,  it  would 
rou-.e  it  by  looking  up  MX  RRs  for  ISI.EDU.  The  MX  RRs  at  ISI.EDU  namie 
VEN'ERA .  1 3 1  .  ED’J  and  VAXA.ISI.EDU,  and  type  A  queries  can  find  the  host 
addresses  . 

S.2.  Mailbox  binding  (Experi.mental) 

In  mailbox  binding,  the  mailer  uses  the  entire  mail  destination 
.specification  to  construct  a  domain  na.me .  The  encoded  domain  name  for 
the  mailbox  is  used  as  the  QNAME  field  in  a  QTYPE=MAILB  query. 

Several  outco.mes  are  possible  for  this  query: 
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1.  The  query  can  return  a  name  error  indicating  that  the  mailbox 
dees  not  exist  as  a  domain  namie . 

In  the  long  terrr^,  this  would  indicate  that  the  specified 
rt^iilhox  doesn't  exist.  However,  until  the  use  of  mailbox 
binding  is  universal,  this  error  condition  should  be 
interpreted  to  mean  that  the  organization  identified  by  the 
gitbal  part  does  not  support  mailbox  binding.  The 
appropriate  procedure  is  to  revert  to  exchange  binding  at 


2.  :  :.e  query  can  return  a  Mail  Rename  (MR)  F.R . 

The  .MR  RR  carries  new  m.ailbox  specification  in  its  RDATA 
f:ei:;.  The  mailer  should  replace  the  old  mailbox  with  the 
new  ne  and  retry  the  operation. 

1.  Tno'  q'.;ery  can  return  a  M3  RR . 

The  MB  R.R  carries  a  domain  name  for  a  host  in  its  RDATA 
fir.-lu.  The  mailer  should  deliver  the  rr.essage  to  that  host 
via  whatever  protocol  is  applicable,  e.g.,  b,SMTP. 

4.  Tne  query  can  return  one  or  more  Mail  Group  (MG)  RRs . 

This  condition  means  that  the  mailbo.x  was  actually  a  mailing 
mail  group,  rather  than  a  single  mailbox.  Each  MG  RR 
DATA  field  that  identifies  a  mailbox  that  is  a  member 
f  the  group.  The  mailer  should  deliver  a  copy  of  the 
message  to  each  member. 

5 .  The  query  can  return  a  KB  RR  as  well  as  one  or  more  MG  RRs . 

This  condition  means  the  the  mailbox  was  actually  a  mailing 
li.st.  The  mailer  can  either  deliver  the  message  to  the  host 
specified  by  the  MB  RR,  which  will  in  turn  do  the  delivery  tc 
all  .mc-.Tbers,  or  the  m.ailer  can  use  the  .MG  R.Rs  to  do  the 
expansion  itself. 

I any  of  these  cases,  the  response  may  include  a  Mail  Information 
(MINFl)  RR.  This  RR  is  usually  associated  with  a  mail  group,  but  is 
legal  with  a  MB.  The  MINFO  RR  identifies  tv;o  mailboxes.  One  of  these 
iier.tifies  a  responsible  person  for  the  original  mailbox  name.  This 
m.ailh'‘x  should  be  used  for  requests  to  be  added  to  a  mail  group,  etc. 

Tr.e  second  miailbox  name  in  the  MINFO  RR  identifies  a  mailbox  that  should 
receive  error  messages  for  mail  failures.  This  is  particularly 
appropriate  for  mailing  liscs  when  errors  in  member  names  should  be 
tt:-por*:ed  to  a  person  other  than  the  one  who  sends  a  message  to  the  list. 
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New  fields  may  be  added  to  this  RR  in  the  future. 
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Updates;  RFCs  1034,  1035 


P.  Mockapetris 
ISI 

April  1989 


DNS  Encoding  of  Network  Names  and  Other  Types 


1 .  STATUS  OF  THIS  MEMO 

This  RFC  proposes  two  extensions  to  the  Domain  Name  System: 

-  A  specific  method  for  entering  and  retrieving  RRs  which  map 
between  network  names  and  numbers. 

-  Ideas  for  a  general  method  for  describing  mappings  between 
arbitrary  identifiers  and  numloers . 

The  method  for  mapping  between  network  names  and  addresses  is  a 
proposed  standard,  the  ideas  for  a  general  method  are  experimental. 

This  RFC  assumes  that  the  reader  is  familiar  with  the  DNS  [RFC  1034, 
RFC  1035]  and  its  use.  The  data  shown  is  for  pedagogical  use  and 
does  not  necessarily  reflect  the  real  Internet. 

Distribution  of  this  memo  is  unlimited. 

2.  INTRODUCTION 

The  DNS  is  extensible  and  can  be  used  for  a  virtually  unlimited 
number  of  data  types,  name  spaces,  etc.  New  type  definitions  are 
occasionally  necessary  as  are  revisions  or  deletions  of  old  types 
(e.g.,  MX  replacement  of  MD  and  MF  [RFC  974]),  and  changes  described 
in  [RFC  973] .  This  RFC  describes  changes  due  to  the  general  need  to 
map  between  identifiers  and  values,  and  a  specific  need  for  network 
name  support . 

Users  wish  to  be  able  to  use  the  DNS  to  map  between  network  names  and 
numbers.  This  need  is  the  only  capability  found  in  HOSTS.TXT  which 
is  not  available  from  the  DNS.  In  designing  a  method  to  do  this, 
there  were  two  major  areas  of  concern; 

-  Several  tradeoffs  involving  control  of  network  names,  the 
syntax  of  network  names,  backward  compatibility,  etc. 

-  A  desire  to  create  a  method  which  would  be  sufficiently 
general  to  set  a  good  precedent  for  future  mappings, 
for  example,  between  TCP-port  names  and  numbers. 


Mockapetris 


[Page  1] 


4-123 


INTERNET  PROTOCOL  HANDBOOK  -  Volume  Four 


1989 


RFC  1101  DNS  Encoding  of  Network  Names  and  Other  Types  April  1989 


autonomous  system  names  and  numbers,  X.500  Relative 
Distinguished  Names  (RDNs)  and  their  servers,  or  whatever. 

It  was  impossible  to  reconcile  these  two  areas  of  concern  for  network 
names  because  of  the  desire  to  unify  network  number  support  within 
existing  IP  address  to  host  name  support.  The  existing  support  is 
the  IN-ADDR.ARPA  section  of  the  DNS  name  space.  As  a  result  this  RFC 
describes  one  structure  for  network  names  which  builds  on  the 
existing  support  for  host  names,  and  another  family  of  structures  for 
future  yellow  pages  (YP)  functions  such  as  conversions  between  TCP- 
port  numbers  and  mnemonics. 

Both  structures  are  described  in  following  sections.  Each  structure 
has  a  discussion  of  design  issues  and  specific  structure 
recommendations . 

We  wish  to  avoid  defining  structures  and  methods  which  can  work  but 
do  not  because  of  indifference  or  errors  on  the  part  of  system 
administrators  when  maintaining  the  database.  The  WKS  RR  is  an 
example.  Thus,  while  we  favor  distribution  as  a  general  method,  we 
also  recognize  that  centrally  maintained  tables  (such  as  HOSTS.TXT) 
are  usually  more  consistent  though  less  maintainable  and  timely. 

Hence  we  recommend  both  specific  methods  for  mapping  network  names, 
addresses,  and  subnets,  as  well  as  an  instance  of  the  general  method 
for  mapping  between  allocated  network  numbers  and  network  names. 
(Allocation  is  centrally  performed  by  the  SRI  Network  Information 
Center,  aka  the  NIC) . 

3.  NETWORK  NAME  ISSUES  AND  DISCUSSION 

The  issues  involved  in  the  design  were  the  definition  of  network  name 
syntax,  the  mappings  to  be  provided,  and  possible  support  for  similar 
functions  at  the  subnet  level. 

3.1.  Network  name  syntax 

The  current  syntax  for  network  names,  as  defined  by  [RFC  952]  is  an 
alphanumeric  string  of  up  to  24  characters,  which  begins  with  an 
alpha,  and  may  include  " . "  and  except  as  first  and  last 

characters.  This  is  the  format  which  was  also  used  for  host  names 
before  the  DNS.  Upward  compatibility  with  existing  names  might  be  a 
goal  itF  any  new  scheme. 

However,  the  present  syntax  has  been  used  to  define  a  flat  name 
space,  and  hence  would  prohibit  the  same  distributed  name  allocation 
method  used  for  host  names.  There  is  some  sentiment  for  allowing  the 
NIC  to  continue  to  allocate  and  regulate  network  names,  much  as  it 
allocates  numbers,  but  the  majority  opinion  favors  local  control  of 
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network  names.  Althougn  it  would  be  possible  to  provide  a  flat  space 
or  a  name  space  in  which,  for  example,  the  last  label  of  a  domain 
name  captured  the  old-style  network  name,  any  such  approach  would  add 
complexity  to  the  method  and  create  different  rules  for  network  names 
and  host  names . 

For  these  reasons,  we  assume  that  the  syntax  of  network  names  will  be 
the  same  as  the  expanded  syntax  for  host  names  permitted  in  [HR] . 

The  new  syntax  expands  the  set  of  names  to  allow  leading  digits,  so 
long  as  the  resulting  representations  do  not  conflict  with  IP 
addresses  in  decimal  octet  form.  For  example,  3Com.COM  and  3M.COM 
are  now  legal,  although  2 6 . 0 . 0 . 73 . COM  is  not.  See  [HR]  for  details. 

The  price  is  that  network  names  will  get  as  complicated  as  host 
names.  An  administrator  will  be  able  to  create  network  names  in  any 
do.main  under  his  control,  and  also  create  network  number  to  name 
ntries  in  IN-ADDR.ARPA  domains  under  his  control.  Thus,  the  name 
or  the  ARPANET  might  become  NET.ARPA,  ARPANET.ARPA  or  Arpa- 
network , MIL . ,  depending  on  the  preferences  of  the  owner. 

3.2.  Mappings 

The  desired  mappings,  ranked  by  priority  with  most  important  first, 
a  re  : 


-  Mapping  a  IP  address  or  network  number  to  a  network  name. 

This  mapping  is  for  use  in  debugging  tools  and  status  displays 
of  various  sorts.  The  conversion  from  IP  address  to  network 
number  is  well  known  for  class  A,  B,  and  C  IP  addresses,  and 
involves  a  simple  mask  operation.  The  needs  of  other  classes 
are  not  yet  defined  and  are  ignored  for  the  rest  of  this  RFC. 

-  Mapping  a  network  name  to  a  network  address. 

This  facility  is  of  less  obvious  application,  but  a 
symmetrical  mapping  seems  desirable. 

-  Mapping  an  organization  to  its  network  names  and  numbers. 

This  facility  is  useful  because  it  may  not  always  be  possible 
to  guess  the  local  choice  for  network  names,  but  the 
organization  name  is  often  well  known. 

-  .Similar  mappings  for  subnets,  even  when  nested. 

The  primary  application  is  to  be  able  to  identify  all  of  the 
subnets  involved  in  a  particular  IP  address.  A  secondary 
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requirement  is  to  retrieve  address  mask  inf crmct icn . 

3.3.  Network  address  section  of  the  name  space 

The  network  name  syntax  discussed  above  can  provide  domain  names 
which  will  contain  mappings  from  network  names  to  various  quantities, 
but  we  also  need  a  section  of  the  name  space,  organized  by  network 
and  subnet  number  to  hold  the  inverse  mappings. 

The  choices  include: 

-  The  same  network  number  slots  already  assigned  and  delegated 
in  the  IN-ADDR.ARPA  section  of  the  name  space. 

For  example,  10 . IN-ADDR. ARPA  for  class  A  net  10, 

2 . 128 . IN-ADDR.ARPA  for  class  B  net  128.2,  etc. 

-  Host-zero  addresses  in  the  IN-ADDR.ARPA  tree.  (A  host  field 
of  all  zero  in  an  IP  address  is  prohibited  because  of 
confusion  related  to  broadcast  addresses,  et  al . ) 

For  example,  0 . 0 . 0 . 10 . IN-ADDR . ARPA  for  class  A  net  10, 

0  .  0 . 2 . 128  .  IN-ADDR.  arpa  for  class  B  net  128.2,  etc.  Like  t.he 
first  scheme,  it  uses  in-place  name  space  delegations  to 
distribute  control. 

The  main  advantage  of  this  scheme  over  the  first  is  that  it 
allows  convenient  names  for  subnets  as  well  as  networks.  A 
secondary  advantage  is  that  it  uses  names  which  are  not  in  use 
already,  and  hence  it  is  possible  to  test  whether  an 
organization  has  entered  this  information  in  its  domain 
database  . 

-  Some  new  section  of  the  name  space. 

While  this  option  provides  the  most  opportunities,  it  creates 
a  need  to  delegate  a  whole  new  name  space.  Since  the  IP 
address  space  is  so  closely  related  to  the  network  number 
space,  most  believe  that  the  overhead  of  creating  such  a  new 
space  is  overwhelming  and  would  lead  to  the  WKS  syndrome.  <As 
of  February,  1989,  approximately  400  sections  of  the 
IN-ADDR.ARPA  tree  are  already  delegated,  usually  at  network 
boundaries . ) 
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4.  SPECIFICS  FOR  NETWORK  NAME  MAPPINGS 

The  proposed  solution  uses  information  stored  at: 

-  Names  in  the  IN-ADDR.ARPA  tree  that  correspond  to  host-zero  IP 
addresses.  The  same  method  is  used  for  subnets  in  a  nested 
fashion.  For  e.xample,  0 . 0 . 0 . 10  .  IN-ADDR  .  ARPA  .  for  net  10. 

Two  types  of  information  are  stored  here:  PTR  RRs  which  point 
to  the  network  name  in  their  data  sections,  and  A  RRs,  which 
are  present  if  the  network  (or  subnet;  is  subnetted  further. 

If  a  type  A  RR  is  present,  then  it  has  the  address  mask  as  its 
data.  The  general  form  is: 

<reversed-host-zero-number> . IN-ADDR. ARPA.  PTR  <network-name> 
<reversed-host -zero-number> . IN-ADDR . ARPA .  A  <subnet-mask> 

For  example: 

0 . 0 . 0 . 10 . IN-ADDR. ARPA.  PTR  ARPANET . ARPA . 

or 

0  .  0 . 2 . 12 8 . IN-ADDR . ARPA .  PTR  cmu-net.cmu.edu. 

A  255.255.255.0 

In  general,  this  information  will  be  added  to  an  existing 
m.aster  file  for  some  IN-ADDR "^PA  domain  for  each  network 
involved.  Similar  RRs  can  be  i^sed  at  host-zero  subnet 
ent  r ies . 

-  Names  which  are  network  names. 

The  data  stored  here  is  PTR  RRs  pointing  at  the  host-zero 
entries.  The  general  form  is: 

<network-name>  ptr  <reversed-ho3t-zero-number> . IN-ADDR . ARPA 
For  example : 

ARP  ANET  .  ARPA  .  PTR  O.h  0 . 1  0  .  _ 

or 

isi-net.isi.edu.  PTR  0 . 0 . 9 . 128 . IN-ADDR . ARPA . 

In  general,  this  information  will  be  inserted  in  the  master 
file  for  the  domain  name  of  the  organization;  this  is  a 
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different  file  from  that  which  holds  the  information  below 
IN-ADDR .  AF.PA .  Similar  FTP,  RF.s  can  be  used  at  subnet  namies  . 

-  Names  corresponding  to  organizations. 

The  data  here  is  one  or  rrLore  PTR  RRs  pointing  at  the 
IN-.ADD.R .  A.RrA  names  corresponding  to  host-zero  entries  for 
.net wo r ks  . 

For  example; 


ISI.EDU.  PTR  0  .  0 . 9 . 12  8  .  IN-AS:^DR  .  ARPA  . 

MCC.COM.  PTR  0 . 167 . 5 . 192 . IN-ADDR . ARPA. 

PTR  0 . 168 . 5 . 192 . IN-ADDR .ARPA. 

PTR  0 . 169 . 5 . 192 . IN-ADDR. ARPA. 

PTR  0 . 0 . 62 . 128 . IN-ADDR. ARPA. 

4.1.  A  simpile  e.xample 

The  ARPANET  is  a  Class  A  network  without  subnets.  The  RRs  which 
would  be  added,  assuming  the  ARP AfJET .  ARPA  was  selected  as  a  network 
.name,  would  be: 


ARPANET. ARPA. 


1  .  0  .  10  .  IN-ADDR.  ARPA.  PTR 


0.0.0.10. IN-ADDR . ARPA . 


0.0  O.IO  IN-ADDR. ARPA. 


ARPANET. ARPA. 


T.-.e  first  RR  states  that  the  organization  named  ARPA  owns  n-^^t  10  (It 
m.ight  also  own  more  network  numJoers,  and  these  would  be  represented 
with  an  additional  RR  per  net.)  The  second  states  that  the  network 
name  ARPANET . ARPA .  maps  to  net  10.  The  last  states  that  net  10  is 
r.am.ed  ARPANET  .  ARPA  . 

Note  that  ail  of  the  usual  host  and  corresponding  I.N-ADDR .  ARPA 
entries  would  still  be  required. 

4.2.  A  com.pl icated,  subnetted  exaruplc; 

The  ISI  network  is  128.9,  a  class  B  numloer.  Suppose  the  ISI  network 
was  organized  into  two  levels  of  subnet,  with  the  first  level  using 
an  additional  8  bits  of  address,  a. id  the  second  level  using  4  bits, 
for  address  masks  of  x'FFFFFFOO'  and  X'FFFFFFFO'. 

Then  the  following  RRs  woul,d  be  entered  in  ISI's  master  file  for  the 
ISI. EDU  zone  : 


M  0  o  k  a  t;e  t  r  i  s 
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;  ::efine 

network  entry 

isi-r;ot:  ,  i 

sr.ed'u. 

PTR 

o 

o 

128 . IN-ADDR. ARPA. 

; 

trrst  level  subnets 

1  ~  3  ^4  i'  r'. 

el  .  131  -cr-l'l. 

PTR 

0.1.9. 

128  .  IN-AD'DR.  ARPA. 

div2-surr. 

el  .  13  1 . 0  11 3  . 

PTR 

0.2.9. 

128 . IN-ADDR. ARPA. 

;  Define 

second  level  subnets 

1  r.  3  “  3  u  r.;  3  u 

bnei . isi .edu . 

PTR 

16.2.9 

. 128 . IN-ADDR. ARPA 

In  t  ne  9  . 

1 2 8 . IM-AbOR . ARPA  zone: 

;  Define 

network  number  and  address 

mask 

C . 0 . 9  .  12  8 

. IN-ADDR. ARPA. 

PTR 

isi-ne 

t . is i . edu . 

255.255.255.0 


•aka  X'EFFFFFOO' 


;  Define  one  of  the  first  level  subnet  numbers  and  masks 
0 . 1 . 9 . 128 . IN-ADDR. ARPA.  PTR  divl-subnet.isi.edu. 

A  255. 255. 255. 240  ;aka  X'FFFFFFFC' 

;  Define  another  first  level  subnet  number  and  mask 
C . 2 . 9 . 128 . IN-ADDR. ARPA.  PTR  div2-subnet.isi.edu. 

A  255.255.255.240  ;aka  X'FFFFFFFO' 

;  Define  second  level  subnet  nu.tiber 

1  6 . 2  .  9  .  12  8  .  IN-ADDR .  AREA  .  PTR  inc-s'ubsubnet  .  isi  .  edu  . 

This  assu.mes  that  the  ISI  network  is  named  isi-net .  isi  .  edu  .  ,  first 
level  subnets  are  named  divl-subnet.isi.edu.  and  div2- 
subnet . is i . edu . ,  and  a  second  level  subnet  is  called  inc- 
3ubsubnet.isi.edu.  (In  a  real  system  as  complicated  as  this  there 
would  be  mere  first  and  second  level  subnets  defined,  but  we  have 
shown  enough  to  illustrate  the  ideas.) 

4.3.  Procedure  for  using  an  IP  address  to  get  network  name 

ending  on  whether  the  IP  address  is  class  A,  B,  or  C,  mask  off  the 
h  one,  two,  or  three  bytes,  respectively.  Reverse  the  octets, 
fix  I.N'-ADDR .  ARP  A,  and  do  a  PTR  query. 

For  exarrple,  suppose  the  IP  address  is  10.0.0.51. 

1.  Since  this  is  a  class  A  address,  use  a  mask  x'FFOOOOOO'  and 
get  10.0.0.0. 

2.  Soristruct  the  name  0 . 0 . 0 . 1  0  .  IN-AD'DR  .  ARPA  . 

3.  Do  a  PTR  query.  Set  back 
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0 . 0 . 0 . 10 . IN-ADDR. ARPA.  PTR  ARPANET . ARPA . 

4.  Conclude  that  the  network  name  is  "ARPANET . ARPA . " 

Suppose  that  the  IP  address  is  128.9.2.17. 

1.  Since  this  is  a  class  B  address,  use  a  mack  of  x'FFFFOOOO' 
and  get  128.9.0.0. 

2.  Construct  the  name  0 . 0 . 9 . 128 . IN-ADDR . ARPA . 

3.  Do  a  PTR  query.  Get  back 

0 . 0 . 9 . 128 . IN-ADDK.ARPA.  PTR  isi-net.isi.edu 

4.  Conclude  that  the  network  name  is  "isi-net.isi.edu." 

4.4.  Procedure  for  finding  all  subnets  involved  with  an  IP  address 

This  is  a  simple  extension  of  the  IP  address  to  network  name  method. 
When  the  network  entry  is  located,  do  a  lookup  for  a  possible  A  RR. 

If  the  A  RR  is  found,  look  up  the  next  level  of  subnet  using  the 
original  IP  address  and  the  mask  in  the  A  RR.  Repeat  this  procedure 
until  no  A  RR  is  found. 


For  example,  repeating  the  use  of  128.9.2.17. 


1.  As  before  construct  a  query  for  0 . 0 . 9 . 12 8 . IN-ADDR . ARPA . 
Retrieve : 


0 . 0 . 9 . 128 . IN-ADDR. ARPA.  PTR 

A 


isi-net.isi.edu. 

255.255.255.0 


2.  Since  an  A  RR  was  found,  repeat  using  mask  from  RR 
(255.255.255.0),  constructing  a  query  for 
0 . 2 . 9 . 128 . IN-ADDR. ARPA.  Retrieve: 


0 . 2 . 9 . 128 . IN-ADDR. ARPA.  PTR 

A 


div2 -subnet . isi . edu . 
255.255.255.240 


3.  Since  another  A  RR  was  found,  repeat  using  mask 

2  55.255.255.240  (x' FFFFFFFO ' )  .  constructing  a  query  for 

16.2.9.128. IN-ADDR. ARPA.  Retrieve : 


16 . 2 . 9 . 128 . IN-ADDR. ARPA.  PTR  inc-subsubnet.isi.edu. 


4.  Since  no  A  RR  is  present  at  1 6 . 2 . 9 . 12 8 . IN-ADDR . ARPA . ,  there 
are  no  more  subnet  levels. 
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5.  YP  ISSUES  AND  DISCUSSION 


The  term  "Yellow  Pages"  is  used  in  almost  as  many  ways  as  the  term 
"domain",  so  it  is  useful  to  define  what  is  m.eant  herein  by  YP .  The 
general  problem  to  be  solved  is  to  create  a  method  for  creatine 
mappings  from  one  kind  of  identifier  to  another,  often  with  an 
inverse  capability.  The  traditional  methods  are  to  search  or  use  a 
precomputed  index  of  some  kind. 

Searching  is  imipractical  when  the  search  is  too  large,  and 
precomputed  indexes  are  possible  only  when  it  is  possible  to  specify 
search  criteria  in  advance,  and  pay  for  the  resources  necessary  to 
build  the  index.  For  example,  it  is  impractical  to  search  the  entire 
do.main  tree  to  find  a  particular  address  RR,  so  we  build  the  IN- 
ADDR.ARPA  YP .  Similarly,  we  could  never  build  an  Internet-wide  index 
of  "hosts  with  a  load  average  of  less  than  2”  in  less  time  than  it 
would  take  for  the  data  to  change,  so  indexes  are  a  useless  approach 
for  that  probleiTi. 

Such  a  precomputed  index  is  what  we  mean  by  YP,  and  we  regard  the 
IN-ADDR.ARPA  domain  as  the  first  instance  of  a  YP  in  the  DNS. 

Although  a  single,  centrally-managed  YP  for  well-known  values  such  as 
TCP-port  is  desirable,  we  regard  organization-specific  YPs  for,  say, 
locally  defined  TCP  ports  as  a  natural  exte.nsioii,  as  are  combinations 
of  YPs  using  search  lists  to  merge  the  two. 

In  examining  Internet  Nu.mbers  (RFC  997]  and  Assigned  Numbers  [RFC 
1010],  it  is  clear  that  there  are  several  m.appings  which  might  be  of 
value.  For  example: 

<assigned-netwoik-n3me>  <==>  <IP-address> 

<autonomou3-system-id>  <==>  <number> 

<protocol-id>  <==>  <number> 

<port-id>  <==>  <number> 

<ethe met -type>  <==>  <number> 

<public-data-net>  <==>  <lP-address> 


Following  the  IN-ADDR  example,  the  YP  takes  the  form  of  a  domain  tree 
organized  tc  optimize  retrieval  by  search  key  and  distribution  via 
normal  DNS  rules.  The  name  used  as  a  key  must  include: 

1.  A  well  known  origin.  For  example,  IN-ADDR.ARPA  is  the 
current  IP-address  to  host  name  YP . 

2.  A  "froni"  data  type.  This  identifies  the  input  type  of  the 
m.apping.  This  is  necessary  because  we  may  be  mapping 
sotriething  as  anonymous  as  a  number  to  any  number  of 
rrinemonics,  etc. 
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3.  A  "to"  data  type.  Since  we  assum.e  several  symrriet  r  ical 
rrjtem.onic  <==>  nurriter  mappings,  this  is  also  necessary. 

This  ordering  reflects  the  natural  scoping  of  control,  and  hence  the 
order  of  the  compo.nents  in  a  domain  name.  Thus  domain  names  would  be 
of  the  form; 

<f  rom-value> . <to-data-type> . <f  rom-data-type> . <YP-origin> 

To  make  this  work,  we  need  to  define  well-know  strings  for  each  of 
these  metavariables,  as  well  as  encoding  rules  for  converting  a 
<from-value>  into  a  domain  name.  We  might  define: 

<YP-origin>  : =YP 

<f rom-data-type> ; =TCP -port  I  IN-ADDR  (  Number  I 

Assigned-network-number  1  Name 
<to-data-type>  : =<f rom-data-type> 

Note  that  "YP"  is  NOT  a  valid  country  code  under  [ISO  3166]  (although 
we  may  want  to  worry  about  the  future) ,  and  the  existence  of  a 
syntactically  valid  <to-data-type> .<f rom-data-type>  pair  does  not 
im.ply  that  a  meaningful  mapping  exists,  or  is  even  possible. 

The  encoding  rules  might  be: 

TCP-port  Six  character  alphanu.meric 

IN-ADDR  Reversed  4-octet  decimal  string 

Number  decimal  integer 

Assigned-network-number 

Reversed  4-octet  decimal  string 

.Na.me  Domain  namiC 

6.  SPECIFICS  FOR  YP  MAPPINGS 

6.1.  TCP-PCRT 

Sorigin  Number . TCP-port . YP . 

23  PTR  TELNET .TCP-port .Number .YP . 

25  PTR  SMTP .TCP-port . Number . YP . 

Sorigin  TCP -port . Numbe r . YP . 

TELNET  PTR  2 3 . Number . TCP-port . YP . 
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SMTP  PTR  25 .Number .TCP-port .YP . 

Thus  the  mapping  between  23  and  TELNET  is  represented  by  a  pair  of 
PTR  RRs,  one  for  each  direction  of  the  mapping. 

6.2.  Assigned  networks 

Network  numbers  are  assigned  by  the  NIC  and  reported  in  "Internet 
Numbers"  RFCs .  To  create  a  YP ,  the  NIC  would  set  up  two  domains: 

Namie  .  Ass  igned-net  work -number  .  YP  and  As  signed-net  work-number  .  YP 

The  first  would  contain  entries  of  the  form: 

So rig in  Name . As signed- net work -number . YP . 

0.0. 0.4  PTR  SATNET . Assigned-networ k-number . Name . YP . 

0.0.0.10  PTR  ARPANET . Assigned-network-number . Name . YP . 

The  second  would  contain  entries  of  the  form: 

Sorigin  As  s  igned-net  wo  r  k -nurtLOe  r  .  Name  .  YP  . 

SAT^iET  .  PTR  0 . 0 . 0 . 4  .  Name  .  Assigned-network-number  .  Y?  . 

ARPANET.  PTR  0 . 0 . 0 . 1 0 . Name . Ass igned-networ k-number . YP . 

These  YPs  are  not  in  conflict  with  the  network  name  support  described 
in  the  first  half  of  t.his  RFC  since  they  map  between  ASSIGNED  network 
names  and  numbers,  not  those  allocated  by  the  organizations 
themselves.  That  is,  they  document  the  NIC’s  decisions  about 
allocating  network  numbers  but  do  not  automatically  track  any 
renaming  performed  by  the  new  owners. 

As  a  practical  m.atter,  we  might  want  to  create  both  of  these  domains 
to  enable  users  on  the  Internet  to  experiment  with  centrally 
maintained  support  as  well  as  the  distributed  version,  or  might  want 
to  implement  only  the  allocated  number  to  name  mapping  and  request 
organizations  to  convert  their  allocated  network  names  to  the  network 
na.mes  described  in  the  distributed  model. 

6.3.  Operational  improvem.ents 

We  could  im.agine  that  all  conversion  routines  using  these  YPs  might 
be  instructed  to  use  " YP . <local-domain>"  followed  by  "YP."  as  a 
search  list.  Thus,  if  the  organization  ISI.EDU  wished  to  define 
locally  mieaningful  TCP-PORT,  it  would  define  the  domains: 

<TCP-port . Number . YP . ISI . EDU>  and  <Number . TCP-port . YP . ISI . EDU> . 
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We  could  add  another  level  of  indirection  in  the  Y?  lookup,  defining 
the  <to-data-type>  .  <f  rorrt-data-type> .  <YP-origin>  nodes  to  point  to  the 
Y?  tree,  rather  than  being  the  Y?  tree  directly.  This  would  enable 
entries  of  the  form; 

IN-ADDR  .  Netname  .  YP  .  PT.E  IN-.ADDR  .  ARPA  . 

to  splice  in  YPs  from  other  origins  or  e;<isting  spaces. 

.Another  possibility  would  be  to  shcrten  the  RD.AT.A  section  of  the  RRs 
which  map  back  a.nd  fcrt.h  by  deleting  the  origin.  This  could  be  done 
either  by  allowing  the  domain  r.a.me  in  the  RD.AT.A  portion  to  not 
ide.ntify  a  real  domain  name,  or  by  defining  a  new  RR  which  used  a 
siirple  te.xt  string  rather  than  a  domain  name. 

Thus,  we  mdght  replace 

$0 rig in  Ass igned- net work -number . Name . YP . 

SATNET .  PTR  0 . 0 . 0 . 4 . Name . Ass igned-net work-number . YP . 

ARPANET.  PTR  0 . 0 . 0 . 1 0 . Name . Ass igned-net work-number . YP . 

with 


Sorigin  Assigned-ne 

SATNET.  PTR 

ARP;uNET.  PTR 


work -number . Name . YP . 

0 . 0 . 0 . 4  . 
0.0.0.10. 


$or igin  Ass igned- net work -number . Name . YP . 

SATNET.  PTT  "0.0. 0.4" 

ARPAJs’ET.  PTT  "0.0.0.10" 

where  PTT  is  a  new  type  whose  RDATA  section  is  a  text  string. 
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Domain  Requirements 


Status  of  this  Memo 

This  memo  is  a  policy  statement  on  the  requirements  of  establishing  a 
new  domain  in  the  ARPA-Internet  and  the  DARPA  research  community. 

This  is  an  official  policy  statement  of  the  TAB  and  the  DARPA. 
Distribution  of  this  memo  is  unlimited. 

Introduction 


This  memo  restates  and  refines  the  requirements  on  establishing  a 
Domain  first  described  in  RFC-881  [1].  It  adds  considerable  detail 
to  that  discussion,  and  introduces  the  limited  set  of  top  level 
doma ins . 

The  Purpose  of  Domains 

Dom>ains  are  administrative  entities.  The  purpose  and  expected  use  of 
domains  is  to  divide  the  name  management  required  of  a  central 
adrr.inistration  and  assign  it  to  sub-administrations.  There  are  no 
geographical,  topological,  or  technological  constraints  on  a  domain. 
The  hosts  in  a  domain  need  not  have  common  hardware  or  software,  nor 
even  common  protocols.  Most  of  the  requirements  and  limitations  on 
domains  are  designed  to  ensure  responsible  administration. 

The  domain  system  is  a  tree-structured  global  name  space  that  has  a, 
few  top  level  domains.  The  top  level  domains  are  subdivided  into 
second  level  domains.  The  second  level  domains  may  be  subdivided 
i.nto  third  level  domains,  and  so  on. 

The  administration  of  a  domain  requires  controlling  the  assignment  of 
names  within  that  domain  and  providing  access  to  the  names  and  name 
related  information  (such  as  addresses)  to  users  both  inside  and 
outside  the  domain. 
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General  Purpose  Domains 

While  the  initial  domain  name  "ARPA"  arises  from  the  history  oi  I'^e 
development  of  this  system  and  environment,  in  the  future  most  of  the 
top  level  names  will  be  very  general  categories  likf^  "government", 
"education",  or  "comum.ercial" .  The  m.otivation  is  to  provide  an 
organization  nam^e  that  is  free  of  undesirable  semantics. 

After  a  short  period  of  initial  experiruentation,  all  current 
ARPA-Internet  hosts  will  select  some  domain  other  than  ARPA  for  their 
future  use.  The  use  of  ARPA  as  a  top  level  domain  will  eventually 
cease . 

Initial  Set  of  Top  Level  Domains 

Ihe  initial  top  level  domain  names  are: 

Temporary 


ARPA  =  The  current  ARPA-Internet  hosts. 


Categories 


GOV 

Government,  any  governmenc  related  domains  .meeting  the 
second  level  requirements. 

EDU 

Education,  any  education  related  domains  meeting  the 
second  level  requirements . 

COM 

= 

Comm^ercial,  any  commercial  related  domains  meeting  the 
second  level  requirements. 

MIL 

Military,  any  military  related  domains  meeting  the 
second  level  requirements. 

ORG 

Organization,  any  other  domains  meeting  the  second 
le/el  requirements. 

Countries 

The  English  two  letter  code  (alpha-2)  identifying  a  country 
according  the  the  ISO  Standard  for  "Codes  for  the 
Representation  of  Names  of  Countries"  [5]. 
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Multiorganizations 

A  multiorganization  may  be  a  top  level  domain  if  it  is  large, 
and  is  composed  of  other  organizations;  particularly  if  the 
multiorganization  can  not  be  easily  classified  into  one  of  the 
categories  and  is  international  in  scope. 

The  following  examples  are  fictions  of  the  authors'  creation,  any 
simr''arity  to  the  real  world  is  coincidental. 

The  UC  Domain 

It  might  be  that  a  large  state  wide  university  with,  say,  nine 
campuses  and  several  laboratories  may  want  ^o  form  a  domain.  Each 
campus  or  major  off-campus  laboratory  ndght  then  be  a  subdomain, 
and  within  each  subdomain,  each  department  could  be  lurcher 
distinguished.  This  university  might  be  a  second  level  domain  in 
the  education  category. 

One  might  see  domain  style  names  for  hosts  in  this  domain  like 
these : 


LOCUS.es.  LA.  Uc.i:.DC 
CCN.OAC.LA.UC.EDU 
ERNIE.CS.CAL.UC.EDU 
A. SI. LLNL.UC.EDU 
A . LAND . LAND . UC . EDU 
NMM . LBL . CAL . UC . EDU 

The  MIT  Domain 

Another  large  university  may  have  many  hosts  using  a  variety  of ■ 
machine  types,  some  even  using  several  families  of  protocols. 
However,  the  administrators  at  this  university  may  see  no  need  for 
the  outside  world  to  be  aware  of  these  internal  differences.  This 
university  might  be  a  second  level  domain  in  the  education 
category . 

One  might  see  domain  style  names  for  hosts  in  this  domain  like 
these : 


APIARY-1 .MIT . EDU 
BABY-BLUE .MIT . EDU 
CEZANNE .MIT . EDU 
DASH.MIT.EDU 
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MULTICS.MIT.EDU 

TAC.MIT.EDU 

XX.MIT.EDU 

The  CSNET  Domain 

There  may  be  a  consortium  of  universities  and  industry  research 
laborator ie.s  called,  say,  "CSNET".  This  CS.NET  is  not  a  network 
po“  "e,  but  r'‘"hcr  a  computer  rruil  exchange  -using  a  variety  of 
protocols  and  network  systems.  Therefore,  CSNET  is  not  a  network 
in  the  oonse  of  the  ARP.ANET,  or  an  Ethernet,  or  even  the 
ARPA-Interr.et ,  but  rather  a  community.  Yet  it  does,  in  fact,  have 
the  key  property  needed  to  form  a  domain;  it  has  a  responsible 
administration.  This  consortium  might  be  large  enough  and  might 
have  membership  that  cuts  across  the  categories  in  such  a  way  that 
it  qualifies  under  tne  "multiorganization  rule"  to  be  a  top  level 
domain . 

One  might  see  domain  style  names  for  hosts  in  this  domain  like 
these : 

CIC. CSNET 
EMORY. CSNET 
GATECH .CSNET 
HP-LABS .CSNET 
SJ. IBM. CSNET 
UDEL. CSNET 
UWISC. CSNET 

.-■•'.eral  Requirements  a  Dwiciain 

There  are  several  requirements  that  .r.u.^t  be  met  to  establish  a 
domain.  In  general,  it  must  be  responsibly  managed.  There  must  be  a 
responsible  person  to  serve  as  an  authoritative  coordinator  for 
domain  related  questions.  There  must  be  a  robust  dorriain  name  lookup 
service,  it  must  be  of  at  least  a  minimum  size,  and  the  domai  must 
be  registered  with  the  central  domain  administrator  (the  Network 
Information  Center  (NIC)  Domain  Registrar) . 

Responsible  Person; 

An  individual  must  be  identified  who  has  authority  for  the 
administration  of  the  names  within  the  domain,  and  who  seriously 
takes  on  the  responsibility  for  the  behavior  of  the  hosts  in  the 
domain,  plus  their  interactions  with  hosts  outside  the  domain. 

This  person  must  have  some  technical  expertise  and  the  authority 
within  the  domain  to  see  that  problems  are  fixed. 
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If  a  host  in  a  given  domain  somehow  misbehaves  in  its  interactions 
with  hosts  outside  the  domain  (e.g  ,  consistently  violates 
protocols) ,  the  responsible  person  for  the  domain  must  be 
competent  and  available  to  receive  reports  of  problems,  take 
action  on  the  reported  problems,  and  follow  through  to  eliminate 
the  problems . 

Domain  Servers: 

A  robust  and  reliable  domain  server  must  be  provided.  One  way  of 
meeting  this  requirement  is  to  provide  at  least  two  independent 
domain  servers  for  the  domain.  The  database  can,  of  course,  be 
the  same.  The  database  can  be  prepared  and  copied  to  each  domain 
server.  But,  the  servers  should  be  in  separate  machines  on 
iridependent  power  supplies,  et  cetera;  basically  as  physically 
independent  as  can  be.  They  should  have  no  common  point  of 
failure . 

Some  domains  may  find  that  providing  a  robust  domain  service  can 
most  easily  be  done  by  cooperating  with  another  domain  where  each 
domain  provides  an  additional  server  for  the  other. 

In  other  situations,  it  may  be  desirable  for  a  domain  to  arrange 
for  domain  service  to  be  provided  by  a  third  party,  perhaps  on 
hosts  located  outside  the  domain. 

One  of  the  difficult  problems  in  operating  a  domain  server  is  the 
acquisition  and  maintenance  of  the  data.  In  this  case,  the  data 
are  the  host  names  and  addresses.  In  some  environments  this 
informiation  changes  fairly  rapidly  and  keeping  up-to-date  data  may 
be  difficult.  This  is  one  motivation  for  sub-domains.  One  may 
wish  to  create  sub-domains  until  the  rate  of  change  of  the  data  in 
a  sub-doiTiain  domain  server  database  is  easily  managed. 

In  the  technical  language  of  the  domain  server  implementation  the 
data  is  divided  into  zones.  Domains  and  zones  are  not  necessarily 
cne-to-one.  It  may  be  reasonable  for  two  or  more  domains  to 
cc.TLbine  their  data  in  a  single  zone. 

The  responsible  person  or  an  identified  technical  assistant  must 
understand  in  detail  the  procedures  for  operating  a  domain  server, 
including  the  management  of  master  files  and  zones. 

Tnc  operation  of  a  domain  server  should  not  be  taken  on  lightly. 
There  u’-e  some  difficult  problems  in  providing  an  adequate 
service,  primarily  the  problems  in  keeping  the  database  up  to 
date,  and  keeping  the  service  operating. 
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The  concepts  and  implementation  details  of  the  domain  server  are 
given  in  RFC-882  [2]  and  RFC-883  [3]. 

Minimum  Size: 

The  dom.ain  miust  be  of  at  least  a  m.iniraum  size.  There  is  no 
requirement  to  form  a  do.main  because  some  set  of  hosts  is  above 
the  minimum  size. 

Top  level  domains  miust  be  specially  authorized.  In  general,  they 
will  only  be  authorized  for  domains  expected  to  have  over  500 
hosts  . 


The  general  guideline  for  a  second  level  dom.ain  is  that  it  have 
over  50  hosts.  This  is  a  very  soft  "requirement".  It  makes  sense 
that  any  major  organization,  such  as  a  university  or  corporation, 
be  allowed  as  a  second  level  domain  --  even  if  it  has  jusr  a  few 
hosts  . 


Registration : 


Top  level  domains  m.ust  be  specially  authorized  and  registered  with 
the  NIC  domain  registrar. 

The  administrator  of  a  level  K  domain  must  register  with  the 
registrar  (or  recponsiblo  person)  of  the  level  N-1  domain.  This 
upper  level  authority  must  be  satisfied  that  the  requirements  are 
met  before  authorization  for  the  domain  is  granted. 

The  registration  procedure  involves  answering  specific  questions 
about  the  prospective  domain.  A  prototype  of  what  the  NIC  Domain 
Registrar  may  ask  for  the  registration  of  a  second  level  domain  is 
shown  below.  These  questions  may  change  from  time  to  time.  It  is 
the  responsibility  of  domain  administrators  to  keep  this 
information  current. 

The  administrator  of  a  domain  is  required  to  make  sure  that  host 
and  sub-domain  names  within  that  jurisdiction  conform  to  the 
standard  name  conventions  and  are  unique  within  that  domain. 

If  sub-do.mains  are  set  up,  the  admini  =;trator  may  wish  to  pass 
along  som.e  of  his  authority  and  responsibility  to  a  sub-domain 
administrator.  Even  if  sub-do.mains  are  established,  the 
responsible  person  for  the  top-level  domain  is  ultimately 
responsible  for  the  whole  tree  of  sub-domains  and  hosts. 

This  does  not  mean  that  a  domain  administrator  has  to  know  the 
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^ietdiis  cf  all  the  sub-domains  and  hosts  to  the  Nth  degree,  but 
simply  that  if  a  problem  occurs  he  can  get  it  fixed  by  calling  on 
the  administrator  of  the  sub-dor.ain  containing  the  problem. 

Top  level  Do.m.ain  Requirements 


There  are  very  few  top 
second  level  domains. 

level  domains. 

each 

of  these  may  have 

many 

.An  initial  set  of  tep  1 
h  as  a  .n  a  dm  inistrator  an 

evel  carries  has 
d  an  agent  . 

been 

identified.  Each 

of  these 

The  top  level  dorr.ains; 


ARPA  =  The  ARP  A- Inte  met 


«  *  *  TEMPORARY  *  *  * 


Admin i s t  r a t  o r : 
Agent : 

Mailbox : 


DARPA 

The  Network  Information  Center 
HOSTMASTER@SRI-NIC.ARPA 


GOV  =  Government 

Aditi n i  s  t  -  1. 1  -  :  D.hP 

Agent:  The  Network  Information  Center 

Mailbox :  KOSTMASTERQSRI-NIC . ARPA 

ECU  =  Education 


Administrator ; 
Agent  : 

Mailbox : 


DARPA 

The  Network  Information  Center 
HOSTMASTER@SRI-NIC . ARPA 


COM  =  Commercial 


Admi nistrator: 
Agent : 

Mailbox : 


DARPA 

The  Network  Information  Center 
HOSTMASTEReSRI-NIC. ARPA 


MIL  =  Military 


Adm inistrator : 
Agent  : 

Ma i Ibox : 


DDN-PMO 

The  Network  Information  Center 
HOST.MASTER9SRI-NIC  .  ARPA 
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ORG  =  Organization 

Adminis r rat  or :  D  \R?A 

Agent:  The  Network  Information  Center 

Mailbox :  HOSTMASTER@ SRI-NIC . ARPA 

Countries 

The  English  two  letter  code  (alpha-2)  identifying  a  country 
according  the  the  ISO  Standard  for  "Codes  for  the 
Representation  of  Names  of  Countries"  [5] . 

As  yet  no  country  dort-oins  have  been  established.  As  they  are 
established  information  about  the  administrators  and  agents 
w_ll  be  made  public,  and  will  be  listed  in  subsequent  editions 
of  this  memo. 

Multiorganizations 

A  multiorganization  may  be  a  top  level  domain  if  it  is  large, 
and  is  composed  of  other  organizations;  particularly  if  the 
multiorganization  can  not  be  easily  classified  iiito  one  of  the 
categories  and  is  international  in  scope. 

As  yet  no  multiorganization  domains  have  been  established.  As 
tuey  are  established  information  about  the  administrators  and 
agents  will  be  made  public,  and  will  be  listed  in  subsequent 
editions  of  this  memo. 

Note:  The  NIC  is  listed  as  the  agent  and  registrar  for  all  the 

currently  allowed  top  level  domains.  If  there  are  other  entities 
that  would  be  more  appropriate  agents  and  registrars  for  some  or 
all  of  these  domains  then  it  would  be  desirable  to  reassign  the 
responsibility . 

Second  Le'-el  Dom.ain  Requirements 

Each  tep  level  domain  m,ay  have  many  second  level  domains.  Every 
second  level  dorriain  must  meet  the  general  requirements  on  a  domain 
specified  above,  and  be  registered  with  a  top  level  domain 
administrator . 
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Third  through  Nth  Level  Domain  Requirements 

Each  second  level  domain  may  have  many  third  level  domains,  etc. 

Every  third  level  domain  (t.hrough  Nth  level  domain)  must  meet  the 
requirements  set  by  the  administrator  of  the  immediately  higher  level 
domain.  Note  t.hat  these  may  be  more  or  less  strict  than  the  general 
requirements.  One  would  expect  the  minimum  size  requirements  to 
decrease  at  each  level. 

The  .\RPA  Domain 

At  the  time  the  implementation  of  the  domain  concept  was  begun  it  was 
thought  that  the  set  of  hosts  under  the  administrative  authority  of 
DARPA  would  make  up  a  domain.  Thus  the  initial  domain  selected  was 
called  ARPA.  Now  it  is  seen  that  there  is  no  strong  motivation  for 
there  to  be  a  top  level  ARPA  domain.  The  plan  is  for  the  current 
ARPA  domain  to  go  out  of  business  as  soon  as  possible.  Hosts  that 
are  currently  members  of  the  .ARPA  domain  should  m.ake  arrangements  to 
join  another  domain.  It  is  likely  that  for  experimental  purposes 
there  will  be  a  second  level  domain  called  ARPA  in  the  ORG  dom.ain 
(i.e.,  there  will  probably  be  an  ARPA.ORG  domain) . 

The  DDN  Hosts 

DDM  hosts  that  do  not  desire  to  participate  in  this  domain  naming 
system  will  continue  to  use  the  HOSTS.TXT  data  file  maintained  by  the 
NIC  for  name  to  address  translations.  This  file  will  be  kept  up  to 
date  for  the  DDN  hosts.  However,  all  DDN  hosts  will  change  their 
names  from  "host. ARPA"  to  {for  example)  "host.DDN.MIL"  some  time  in 
the  future.  The  schedule  for  changes  required  in  DDN  hosts  will  be 
established  by  the  DDN-PMO. 

Impact  on  Hosts 

What  is  a  host  administrator  to  do  about  all  this? 

For  existing  hosts  already  operating  in  the  ARPA-Internet ,  the 
best  advice  is  to  sit  tight  for  now.  Take  a  few  months  to 
consider  the  optio.ns,  then  select  a  domain  to  join.  Plan 
carefully  for  the  im.pact  that  changing  your  host  name  will  have  on 
both  your  local  users  and  on  their  remote  correspondents. 

For  a  new  host,  careful  thought  should  be  given  (as  discussed 
below) .  Some  guidance  can  be  obtained  by  comparing  notes  on  what 
other  hosts  with  similar  administrative  properties  have  done. 

The  owner  of  a  host  may  decide  which  domain  to  join,  and  the 
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administrator  of  a  domain  may  decide  which  hosts  to  accept  into  his 
domain.  Thus  the  owner  of  a  host  and  a  domain  administrator  miust 
com.e  to  an  understanding  about  the  host  being  in  the  domain.  This  is 
she  foundation  of  responsible  administration. 

For  example,  a  host  "XYZ"  at  MIT  m.ight  possible  be  considered  as  a 
candidate  fcr  becoming  any  of  XYZ . AR? A . CRG,  XYZ.CSNET,  or 
X  Y  Z  .  M I  ^  E  D  X 

The  owner  of  .host  XYZ  m.ay  choose  which  domain  to  joir., 
depending  on  which  domain  administrators  are  willing  to  have 
him,. 

The  domain  is  part  of  the  h.cst  r.a.me .  Thus  if  USC- IS  lA .  A.R?A  changes 
its  domain  affiliation  to  DDN.MIL  to  become  USC- I S I A . CDN . Ml L,  it  has 
ed  its  name.  This  means  t.hat  a.ny  previous  references  to 
SIA.ARPA  are  now  out  of  date.  Such  old  references  m.ay  include 
te  host  name  to  address  tables,  and  any  recorded  infor.m.ation 
m.ailboxes  such  as  m.ailing  lists,  the  headers  of  old  messages, 
ed  directories,  a.nd  peoples'  m.em.ories. 

xperience  of  the  DARPA  community  suggests  that  changing  the  nam.e 
fiOst  is  somewhat  painful.  It  is  recomrr, ended  that  careful 
ht  he  given  to  choosing  a  new  name  for  a  host  -  which  includes 
ting  its  place  in  the  dom.ain  hierarchy. 

Th.e  R:les  of  the  Network  Information  Center 

The  NIC  plays  two  types  of  roles  in  the  administration  of  domains. 
F^rst,  the  NIC  is  the  registrar  of  all  top  level  domains.  Second 
the  NIC  is  the  administrator  of  several  top  level  domains  (and  the 
registrar  for  second  level  domains  in  these). 


Tcp  Level  Domain  Registrar 


.As  the  registrar  for  top  level  domains,  the  NIC  is  the  contact 
point  for  investigati.ng  the  possibility  of  establishing  a  new  tcp 
level  domain. 


Top  Level  Do.main  Administrator 

For  the  top  level  domains  designated  so  far,  the  NIC  is  the 
administrator  of  each  of  these  domains.  This  mieans  the  NIC  is 
re.opcn.3ible  for  the  mar.ageme.nt  of  these  do.mains  and  the 
registration  of  the  seco.nd  level  domains  or  hosts  (if  at  the 
.second  level)  in  these  domiains. 
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It  may  be  reasonable  for  the  administration  of  some  of  these 
domains  to  be  taken  on  by  other  authorities  in  the  future.  It  is 
certainly  not  desired  that  the  NIC  be  the  administrator  of  all  top 
level  domains  forever. 

Prototypical  Questions 

To  establish  a  dom.ain,  the  following  information  must  be  provided  to 
the  NIC  Domain  Registrar  (HOSTMASTER@SRI-NIC.ARPA): 

Note:  The  key  people  must  have  computer  mail  mailboxes  and 

NiC-Idents.  If  they  do  not  at  present,  please  remedy  the 
situation  at  once.  A  NIC-Ident  may  be  estaulished  by  contacting 
NIC@SRI-NIC.ARPA. 

1)  The  name  of  the  top  level  domain  to  join. 

For  example:  EDU 

2)  The  name,  title,  mailing  address,  phone  number,  and  organization 
of  the  administrative  head  of  the  organization.  This  is  the  contact 
point  for  administrative  and  policy  questions  about  the  domain.  In 
the  case  of  a  research  project,  this  should  be  the  Principal 
Investigator.  The  online  mailbox  and  NIC-Ident  of  this  person  should 
also  be  included. 

For  example: 

Administrator 

Organization 
Name 
Tit  le 

Mail  Address 


Phone  Number 
Net  Mailbox 
NIC-Ident 


use/ Inf ormat ion  Sciences  Institute 
Keith  Uncapher 
Executive  Director 
USC/ISI 

4676  Admiralty  Way,  Suite  1001 
Marina  del  Rey,  CA.  90292-6695 
213-822-1511 
UncapherSUSC-ISIB . ARPA 
KU 


3)  The  name,  title,  mailing  address,  pi;one  number,  and  organization 
of  the  domain  technical  contact.  The  online  miailbox  and  NIC-Ident  of 
the  domain  technical  contact  should  also  be  included.  This  is  the 
contact  point  for  problems  with  the  domain  and  for  updating 
inform.ation  about  the  domain.  Also,  the  domain  technical  contact  may 
be  responsible  for  hosts  in  this  domain. 
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For  example: 

Technical  Contact 

use/ Inf ormation  Sciences  Institute 
Craig  Milo  Rogers 
Researcher 
USC/ISI 

4676  Admiralty  Way,  Suite  1001 
Marina  del  Rey,  CA.  90292-6695 
213-822-1511 
Rogers@USC-ISIB.ARPA 
CMR 


Organizat ion 

Name 

Title 

Mail  Address 


Phone  Number 
Net  Mailbox 
NIC-Ident 


4)  The  name,  title,  mailing  address,  phone  nu.mber,  and  organization 
of  the  zone  technical  contact.  The  online  r.iailbox  and  NlC-lc-^nt  of 
the  zo.ne  technical  contact  should  also  be  included.  This  is  the 
contact  point  for  problems  with  the  zone  and  for  updating  information 
about  the  zone.  In  many  cases  the  zone  technical  contact  and  the 
dorr.ain  technical  contact  will  be  the  same  person. 

For  e.xample: 

Technical  Contact 


Organization 

Name 

Title 

Mail  Address 


Phone  Number 
Net  Mailbox 
NIC-Ident 


USC/Information  Sciences  Institute 

Craig  Milo  Rogers 

Researcher 

USC/ISI 

4676  Admiralty  Way,  Suite  1001 
Marina  del  Rey,  CA.  90292-6695 
213-822-1511 
Rogers@USC-ISIB. ARPA 
CMR 


5)  The  name  of  the  domain  (up  to  12  characters) .  This  is  the  name 
that  will  be  used  in  tables  and  lists  associating  the  domain  and  the 
dom.ain  server  addres.:..is .  [While  technically  domiain  names  can  be 
quite  long  (programmers  .eware) ,  shorter  names  are  easier  for  people 
to  cope  with . ] 

For  example:  ALPHA-BETA 

6)  A  description  of  the  servers  that  provides  the  domain  service  for 
tra.nslating  name  to  address  for  hosts  in  this  domain,  and  the  date 
they  will  be  operational. 
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A  good  way  to  answer  this  question  is  to  say  "Our  server  is 
supplied  by  person  or  company  X  and  does  whatever  their  standard 
issue  server  does". 

For  example;  Our  server  is  a  copy  of  the  server  operated  by 
the  NIC,  and  will  be  installed  and  made  operational  on 
1 -November- 8 4 . 

7)  A  description  of  the  server  machines,  including: 

(a)  hardware  and  software  (using  keywords  from  the  Assigned 
Numbers ) 

(b)  addresses  (what  host  on  what  net  for  each  connected  net) 

For  example: 

(a)  hardware  and  software 


VAX-1 1/7 50 

and 

UNIX, 

IBM-PC 

and 

MS-DOS, 

dec-1090 

and 

TOPS-20 

(b)  address 

10.9.0.193  on  ARPANET 

8)  An  estimate  of  the  number  of  hosts  that  will  be  in  the  domain. 

(a)  initially, 

(b)  within  one  year, 

(c)  two  years,  and 

(d)  five  years  . 

For  example; 


(a) 

initially  = 

50 

(b) 

one  year  = 

100 

(c) 

two  years  = 

200 

(d) 

five  years  = 

500 
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DOMAIN  ADMINISTRATORS  GUIDE 


STATUS  OF  THIS  MEMO 

This  memo  describes  procedures  for  registering  a  domain  with  the 
Network  Information  Center  (NIC)  of  Defense  Data  Network  (DDN) ,  and 
offers  guidelines  on  the  establishment  and  administration  of  a  domain 
in  accordance  with  the  requirements  specified  in  RFC-920.  It  is 
intended  for  use  by  domain  administrators.  This  memo  should  be  used 
in  conjunction  with  RFC-920,  which  is  an  official  policy  statement  of 
the  Internet  Activities  Board  (lAB)  and  the  Defense  Advanced  Research 
Projects  Agency  (DARPA) .  Distribution  of  this  memo  is  unlimited. 

BACKGROUND 

Domains  are  administrative  entities  that  provide  decentralized 
management  of  host  naming  and  addressing.  The  domain-naming  system 
io  distributed  and  hierarchical. 

The  NIC  is  designated  by  the  Defense  Communications  Agency  (DCA)  to 
provide  registry  oervices  for  the  dc^^ ’ n -naming  system  on  the  DDN  and 
DARPA  portions  of  the  Internet. 

As  registrar  of  top-level  and  second-level  domains,  as  well  as 
administrator  of  the  root  domain  name  servers  on  behalf  of  DARPA  and 
DDN,  the  NIC  is  responsible  for  maintaining  the  root  server  zone 
files  and  their  binary  equivalents.  In  addition,  the  NIC  is 
responsible  for  administering  the  top-level  domains  of  "ARPA, "  "COM," 
"ECU,"  "ORG, "  "GOV,"  and  "MIL"  on  behalf  of  DCA  and  DARPA  until  it 
becomes  feasible  for  other  appropriate  organizations  to  assume  those 
responsibilities  . 

It  is  recommended  that  the  guidelines  described  in  this  document  be 
used  by  domain  administrators  in  the  establishment  and  control  of 
second-level  domains. 

THE  DOMAIN  ADMINISTRATOR 

The  role  of  the  domain  administrator  (DA)  is  that  of  coordinator, 
manager,  and  technician.  If  his  domain  is  established  at  the  second 
level  or  lower  in  the  tree,  the  DA  must  register  by  interacting  with 
the  management  of  the  domain  directly  above  his,  making  certain  that 
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his  domain  satisfies  all  the  requirements  of  the  administration  under 
which  his  domain  would  be  situated.  To  find  out  who  has  authority 
over  the  name  space  he  wishes  to  join,  the  DA  can  ask.  the  NIC 
Kostmaster.  Information  on  contacts  for  the  top-level  and  second- 
level  domains  can  also  be  found  on  line  in  the  file  NETINFO ; DOMAIN- 
CONTACTS  .  TXT  ,  which  is  available  from  the  NIC  via  anonymous  FTP. 

The  DA  should  be  technically  competent;  he  should  understand  the 
concepts  and  procedures  for  operating  a  domain  server,  as  described 
in  RFC-1034,  and  make  sure  that  the  service  provided  is  reliable  and 
uninterrupted.  It  is  his  responsibility  or  that  of  his  delegate  to 
ensure  that  the  data  will  be  current  at  all  times.  As  a  manager,  the 
DA  must  be  able  to  handle  comiplaints  about  service  provided  by  his 
dom.ain  name  server.  He  must  be  aware  of  the  behavior  of  the  hosts  in 
his  domiain,  and  take  prompt  action  on  reports  of  problems,  such  as 
protocol  violations  or  other  serious  misbehavior.  The  administrator 
of  a  dom.ain  m.ust  be  a  responsible  person  who  has  the  authority  to 
either  enforce  these  actions  himself  or  delegate  them  to  someone 
else. 

Name  assignments  within  a  domain  are  controlled  by  the  DA,  who  should 
verify  that  names  are  unique  within  his  dom.ain  and  that  they  conform 
to  standard  naming  conventions.  He  furnishes  access  to  names  and 
narrie-related  information  to  users  both  inside  and  outside  his  domain. 
';e  should  work  closely  with  the  personnel  he  has  designated  as  the 
-.echnical  and  zone"  contacts  for  his  domain,  for  many  administrative 
decisions  will  be  made  on  the  basis  of  input  from  these  people. 

I.'iE  DOMAIN  TECHNICAL  AND  ZONE  CONTACT 

A  zone  consists  of  those  contiguous  parts  of  the  domain  tree  for 
which  a  domain  server  has  complete  information  and  over  which  it  has 
authority.  A  domain  server  may  be  authoritative  for  more  than  one 
zone.  The  ^.o.~‘.ln  ^^^hnical/zc.'.e  contact  is  the  person  who  tends  to 
Che  technical  aspects  of  maintaining  the  domain's  name  server  and 
resolver  software,  and  database  files.  He  keeps  the  name  server 
running,  and  interacts  with  technical  people  in  other  domains  and 
zones  to  solve  problems  that  affect  his  zone. 

POLICIES 

Dom.ain  or  host  name  choices  and  the  allocation  of  domain  name  space 
are  considered  to  be  local  matters.  In  the  event  of  conflicts,  it  is 
the  policy  of  the  NIC  not  to  get  involved  in  local  disputes  or  in  the 
local  decision-making  process.  The  NIC  will  not  act  as  referee  in 
disputes  over  such  matters  as  who  has  the  "right"  to  register  a 
particular  top-level  or  second-level  domain  for  an  organization.  The 
NIC  considers  this  a  private  local  matter  that  must  be  settled  among 
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the  parties  in'-nlved  prior  to  their  commencing  the  registration 
process  with  the  NIC.  Therefore,  it  is  assumed  that  the  responsible 
person  for  a  domain  will  have  resolved  any  local  conflicts  among  the 
.merrbers  of  his  domain  before  registering  that  domain  with  the  NIC. 

The  NIC  will  give  guidance,  if  requested,  by  answering  specific 
technical  questions,  but  will  not  provide  arbitration  in  disputes  at 
the  local  level.  This  policy  is  also  in  keeping  with  the  distributed 
hierarchical  nature  of  the  domain-naming  system  in  that  it  helps  to 
distribute  the  tasks  of  solving  problems  and  handling  questions. 

Naming  conventions  for  -hosts  should  follow  the  rules  specified  in 
RFC-952.  From,  a  technical  standpoint,  domain  names  can  be  very  long. 
Each  segment  of  a  domain  name  may  contain  up  to  64  characters,  but 
the  NIC  strongly  advises  DAs  to  choose  names  that  are  12  characters 
or  fewer,  because  behind  every  domain  system  there  is  a  human  being 
who  must  keep  track  of  the  names,  addresses,  contacts,  and  other  data 
in  a  database.  The  longer  the  name,  the  more  likely  the  data 
rr.aintainer  is  to  make  a  mistake.  Users  also  will  appreciate  shorter 
,  Most  people  agree  that  short  names  are  easier  to  rerriember  and 
type;  most  domain  names  registered  so  far  are  12  characters  or  fewer. 

Domain  nam.e  assignments  are  made  on  a  f irst-come-f irst-served  basis. 
The  NIC  has  chosen  not  to  register  individual  hosts  directly  under 
trie  top-level  domains  it  adrriinisters .  One  advantage  of  the  domain 
naming  system  is  that  administration  and  data  maintenance  can  be 
delegated  down  a  hierarchical  tree.  Registration  of  hosts  at  the 
sam.e  level  in  the  tree  as  a  second-level  domain  would  dilute  the 
usefulness  of  this  feature.  In  addition,  the  administrator  of  a 
domain  is  responsible  for  the  actions  of  hosts  within  his  domain.  We 
would  not  want  to  find  ourselves  in  the  awkward  position  of  policing 
the  actions  of  individual  hosts.  Rather,  the  subdomains  registered 
under  t.-ese  top-level  domains  retain  the  responsibility  for  this 
f unct ion . 

Ci^uiitries  that  wish  to  be  registered  as  top-level  domains  are 
required  to  name  them, selves  after  the  two-letter  country  code  listed 
in  the  international  standard  ISO-3166.  In  some  cases,  however,  the 
two-letter  ISO  country  code  is  identical  to  a  state  code  used  by  the 
U.S.  Postal  Service.  Requests  made  by  countries  to  use  the  three- 
letter  formi  of  country  code  specified  in  the  ISO-3166  standard  will 
be  considered  in  such  cases  so  as  to  prevent  possible  conflicts  and 
con  fusion. 
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HOW  TO  REGISTER 

Obtain  a  domain  questionnaire  from  the  NIC  hostmaster,  or  FTP  the 
file  NETINFO: DOMAIN-TEMPLATE. TXT  from  host  SRI-NIC . ARPA . 

Fill  out  the  questionnaire  completely.  Return  it  via  electronic  mail 
to  HQSTMASTER@SRI-NIC.ARPA. 

The  APPENDIX  to  this  memo  contains  the  application  form  for 
registering  a  top-level  or  second-level  domain  with  the  NIC.  It 
supersedes  the  version  of  the  questionnaire  found  in  RFC-920.  The 
application  should  be  submitted  by  the  person  administratively 
responsible  for  the  domain,  and  must  be  filled  out  completely  before 
the  NIC  will  authorize  establishment  of  a  top-level  or  second-level 
domain.  The  DA  is  responsible  for  keeping  his  domain's  data  current 
with  the  NIC  or  with  the  registration  agent  with  which  his  domain  is 
registered.  For  example,  the  CSNET  and  UUCP  managements  act  as 
dom.ain  filters,  processing  domain  applications  for  their  own 
organizations.  They  pass  pertinent  information  along  periodically  to 
the  NIC  for  incorporation  into  the  domain  database  and  root  server 
files.  The  online  file  NETINFO-ALTERNATE-DOMAIN-PROCEDURE.TXT 
outlines  this  procedure.  It  is  highly  recommended  that  the  DA  review 
this  inform.ation  periodically  and  provide  any  corrections  or 
additions.  Corrections  should  be  submitted  via  electronic  mail. 

:  DO.^lAIN  NAME? 

The  designers  of  the  domain-naming  system  initiated  several  general 
categories  of  names  as  top-level  domain  names,  so  that  each  could 
accomumodate  a  variety  of  organizations.  The  current  top-level 
U'.^...aliio  rey j.oo<.;rc^  with  the  DDN  Network  Information  Center  are  ARPA, 
COM,  EDU,  GOV,  MIL,  NET,  and  ORG,  plus  a  number  of  top-level  country 
doitiains.  To  join  one  of  these,  a  DA  needs  to  be  aware  of  the  purpose 
for  which  it  was  intended. 

"ARPA"  is  a  temporary  domain.  It  is  by  default  appended  to  the 
names  of  hosts  that  have  not  yet  joined  a  domain.  When  the  system 
was  begun  in  1984,  the  names  of  all  hosts  in  the  Official  DoD 
Internet  Host  Table  maintained  by  the  NIC  were  changed  by  adding 
of  the  label  '".ARPA"  in  order  to  accelerate  a  transition  to  the 
domain-naming  system.  Another  reason  for  the  blanket  name  changes 
was  to  force  hosts  to  become  accustomed  to  using  the  new  style 
names  and  to  modify  their  network  software,  if  necessary.  This 
was  done  on  a  network-wide  basis  and  was  directed  by  DCA  in  DDN 
Managem.ent  Bulletin  No.  22.  Hosts  that  fall  into  this  domain  will 
eventually  move  to  other  branches  of  the  domain  tree. 
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"COM"  is  meant  to  incorporate  subdomains  of  companies  and 
businesses  . 

"EDU"  was  initiated  to  accommodate  subdomains  set  up  by 
universities  and  other  educational  institutions. 

"GOV"  e.xists  to  act  as  parent  domain  for  subdomains  set  up  by 
government  agencies. 

"MIL"  was  initiated  to  act  as  parent  to  subdomains  that  are 
developed  by  military  organizations. 

"NET"  was  introduced  as  a  parent  domain  for  various  network-type 
organizations.  Organizations  that  belong  within  this  top-level 
domain  are  generic  or  network-specific,  such  as  network  service 
ce.nters  and  consortia.  "NET"  also  encompasses  network 
manage.ment-related  organizations,  such  as  information  centers  and 
operations  centers. 

"ORG"  exists  as  a  parent  to  subdomains  that  do  not  clearly  fall 
within  the  other  top-level  domains.  This  may  incluae  technical- 
support  groups,  professional  societies,  or  similar  organizations. 

One  of  the  guidelines  in  effect  in  the  domain-naming  system  is  that  a 
host  should  have  only  one  name  regardless  of  what  networks  it  is 
connected  to.  This  implies,  that,  in  general,  domain  names  should 
not  include  routing  information  or  addresses.  For  example,  a  host 
that  has  one  network  connection  to  the  Internet  and  another  to  BITNET 
should  use  the  same  name  when  talking  to  either  network.  For  a 
description  of  the  syntax  of  domain  names,  please  refer  to  Section  3 
of  RFC-10o4. 

VERIFICATION  OF  DATA 

The  verification  process  can  be  accomplished  in  several  ways.  One  of 
these  is  through  the  NIC  WHOIS  server.  If  he  has  access  to  WHOIS, 
the  DA  can  type  the  command  "whois  domain  <domain  name><return>" . 

The  reply  from  WHOIS  will  supply  the  following;  the  name  and  address 
of  the  organization  "owning"  the  domain;  the  name  of  the  domain;  its 
admiinist rat ive ,  technical,  and  zone  contacts;  the  host  names  ana 
network  addresses  of  sites  providing  name  service  for  the  domain. 
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Example ; 

@whois  domain  r  ice  .  ed'o<Returri> 

Rice  University  (RICE-DOM) 

Advanced  Studies  and  Research 
Houston,  TX  77001 

Domiain  Name;  RICE.EDU 

Administrative  Contact  : 

r.ennedy,  Ken  (KK28)  KennedyQ  LLL-CRG .  ARPA  (713)  527-4834 

Technical  Contact,  Zone  Contact: 

Riffle,  Vicky  R.  (VRR)  rif@RICE.EDU 
(713)  527-8101  ext  3844 

Domain  servers: 

RICE.EDU  128.42.5.1 

PENDRAGON.CS.PURDUE.EDU  128.10.2.5 


.alternatively,  the  DA  can  send  an  electronic  mail  message  to 
2 ERVICE3 SRI -NIC . ARPA .  In  the  subject  line  of  the  message  header,  the 
:.A  should  type  "whois  domain  <domain  name>" .  The  requested 
Information  will  be  returned  via  electronic  mail.  This  method  is 
... or.venient  for  sites  that  do  not  have  access  to  the  NIC  WHOIS 
service . 

T''e  initial  application  for  domain  authorization  should  be  submitted 
via  electronic  mail,  if  possible,  to  HOSTMASTER@SRI-NIC.ARPA.  The 
questionnaire  described  in  the  appendix  m^y  be  used  or  a  separate 
application  can  be  FTPed  from  host  SRI-NIC . ARPA .  The  information 
provided  by  the  administrator  will  be  reviewed  by  hostmaster 
personnel  for  completeness.  There  will  most  likely  be  a  few 
e;-:changes  of  correspondence  via  electronic  mail,  the  preferred  method 
of  co.mjTrunication,  prior  to  authorization  of  the  domain. 

HOW  TO  GET  .MORE  INFORMATION 

An  inf o rtLat iona  1  table  of  the  top-level  dom.ains  and  their  root 
servers  is  contained  in  the  file  NETINFO : DOMAINS . TXT  online  at  SRI- 
MIC.ARPA.  This  table  can  be  obtained  by  FTPing  the  file. 
Alternatively,  the  information  can  be  acquired  by  opening  a  TCP  or 
UDP  con.nection  to  the  NIC  Host  Name  Server,  port  101  on  SRI-NIC .  ARPA, 
and  invoking  the  command  "ALL-DOM”. 
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The  following  online  files,  all  available  by  FTP  from  SRI-NIC . ARPA, 
contain  pertinent  domain  information: 

-  NETINFO : DOMAINS . TXT,  a  table  of  all  top-level  domains  and  the 
network  addresses  of  the  machines  providing  domain  name 
service  for  them.  It  is  updated  each  time  a  new  top-level 
domain  is  approved. 

-  NETINFO:DOMAIN-INFO.TXT  contains  a  concise  list  of  all 
top-level  and  second-level  domain  names  registered  with  the 
NIC  and  is  updated  monthly. 

-  NETINFO; DOMAIN-CONTACTS. TXT  also  contains  a  list  of  all  the 
top  level  and  second-level  domains,  but  includes  the 
administrative,  technical  and  zone  contacts  for  each  as  well. 

-  .NETINFO :  DOMAIN-TEMPLATE .  TXT  contains  the  questionnaire  to  be 
completed  before  registering  a  top-level  or  second-level 
domain . 

For  either  general  or  specific  information  on  the  domain  system,  do 
ore  or  more  of  the  following: 

1.  Send  electronic  mail  to  HOSTMASTER@SRI-NIC . ARPA 

2.  Call  the  toll-free  NIC  hotline  at  (800)  235-3155 

3.  Use  FTP  to  get  background  RFCs  and  other  files  maintained 
online  at  the  NIC.  Some  pertinent  RFCs  are  listed  below  i- 
the  REFERENCES  section  of  this  memo. 


.S  t  a  ri  1 


[Page  7] 


4-157 


(j!  a 


IN TKRNET  PROTOCOL  HANDBOOK  -  Volume  Four 


19«9 


DCMAi:;  ADMINISTRATORS  GUID'D 


Nove^rijer  1987 


1  he  re f e r en ::es  listed  here  provide  irr.pcrtarit  background  information 
c;.  the  dorna  in  -  naming  system.  Path  na.mes  of  the  online  files 
available  via  anonymous  FT?  from  the  SRI -N IC . ARP A  host  are  noted  in 
'r  r  a  c  k  e  t  s  . 

1.  Defense  Ccminur. ica t  i  ons  Atpenoy  DDi;  Defense  Corr..T.uri '  _at  ions 
£  s ti rT'. ,  DDN  M(i r..’3 QorTi0 f; ti  Buli‘3t.  ir;  No  .  22,  r.'.jrr.3in  ^23IT.os 
T  r  a  .n  ;3  i  t  i  o  n  ,  Ka  r  c  h  198  4. 

;  DD’N-NDWS  ;DDN-MGT-3ULDETIN-22  .TXT  ] 

efense  Co.Totunicat  ions  Agency  DON  Defense  Comjriun  tea  t  i  ons 
ysterr,,  DON  Ma.nagement  Bulletin  No.  32,  Phase  I  of  the  Pomain 
Ma.t.e  Implementatio.n,  January  1937. 

'  DDN-NEWS ;DDN-MGT-BULDLTXN-32 .TXT  ] 

.'r  .  .Ha  r  rens  t  ien ,  K.,  A.  Stahl,  and  E.  Fei.nler,  ".Hostname 
Server",  RFC-953,  DDN  Network  Information  Center,  SRI 
International.  October  1985.  [  RFC ; RFC3 5 3 . TXT  ] 

-t  .  harrenstien,  K.,  M.  Stahl,  and  E.  Feinler,  "Official  Oo:D 
'r.terr'.et  Host  Table  Specification",  HFC-952,  DD.\'  Network 
Irtfcr.T'.ation  Center,  SRI  International,  October  1  985. 

;  RFC: RFC  9 52. TXT  1 

5.  13  1.',  "Codes  for  the  Representation  of  Karnes  of  Countries", 
ISO-3166,  Internat iona 1  Standards  Organization,  May  1981. 

[  Not  online  ] 

6.  Lazear,  W.D.,  ".MILNET  Na.te  Dorr.ain  Transition",  RFC-1031, 

Mitre  Corporation,  October  1987.  [  RFC : RFC  1 0 3 1 . TXT  ] 

".  Lottor,  M.K.,  "Domain  A'iministrators  Operations  Guide", 

R.F'I-lCSu,  DDN  Network  Inf  or.mat  ion  Center,  SRI  International, 
July  1987.  [  RFC: RFC1033.TXT  ] 

8.  Mcckapetris,  P.,  "Domain  Names  -  Concepts  and  Facilities", 
FFC-10  34  ,  use  Infor.T.ation  Sciences  institute,  October  1987. 

:  RFC  :  .RFCl'O  34  .  TXT  ] 

9.  M„ckapetri.3,  P.,  "Do.m.ain  Names  -  Impleme’’;tat  ion  and 

l.pe  0  i  f  icat  ion"  ,  RFC-1C35,  USC  Inf  oriT;at  io.n  Science.s  Institute, 

O:t  o;.er  1  987.  :  RFC  :  RFC1035  .  TXl  ] 

'.1.  :  .0  okapet  r  i  o> ,  ?.,  "The  Dorr.ain  Name  Systerri",  Proceedings  of  tiie 

IFIP  6.5  Working  Conferonoe  o.o  Computer  Message  Services, 

.f  1 1  ;  :.'jha;r,  E.ngiari  1,  May  1  984.  Al.so  a.3  I S  R;7  -  8  4  -  1  3  3  ,  June 
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1984.  [  Not  online  ] 

11.  Mockapetris,  P.,  J.  Postel,  and  P.  Kirton,  "Name  Server 

Design  for  Distributed  Systems",  Proceedings  of  the  Seventh 
International  Conference  on  Computer  Communication,  October 
30  to  November  3  1984,  Sidney,  Australia.  Also  as 
ISI/RS-84-132,  June  1984.  [  Not  online  ] 

12.  Partridge,  C.,  "Mail  Routing  and  the  Domain  System",  RFC-974, 
CSNET-CIC,  BBN  Laboratories,  January  1986. 

[  RFC : FFC974 . TXT  j 

13.  Postel,  J.,  "The  Dom.ain  Names  Plan  and  Schedule",  RFC-881, 
use  Information  Sciences  Institute,  November  1983. 

[  RFC:RFC881 .TXT  ] 

14.  Reynolds,  J.,  and  Postel,  J.,  "Assigned  Numbers",  RFC-1010 
use  Information  Sciences  Institute,  May  1986. 

[  RFC iRFClOlO .TXT  ] 

15.  Ro.mano,  S.,  and  Stahl,  M.,  "Internet  Numbers",  RFC-1020, 

SRI,  November  1987. 

[  RFC:RFC1020 .TXT  ] 
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The  rollowirig  questionnaire  may  be  FTPed  from  SRI-NIC.ARPA  as 
NET  INFO ; DOMAIN-TEMPLATE . TXT . 


Tc  establish  a  domain,  the  following  information  must  be  sent  to  the 
i;:T  Dom.ain  Registrar  (HOSTMASTEP3SRI-NIC  .  ARPA)  ; 

;.'1TE;  The  key  people  rr\ust  have  elect  rc-nic  m;a ilfcoxes  and  NIC 
"handles,"  unique  NIC  database  identifiers.  If  you  have  access  to 
"V.'HCIS",  please  check  to  see  if  you  are  registered  and  if  so,  make 
sure  the  infor.maticn  is  current.  Include  only  your  handle  and  any 
oh.a.''ges  (if  any)  that  need  to  be  made  in  your  entry.  If  you  do  not 
have  access  to  "WHCIS",  please  provide  all  the  information  indicated 
and  a  NIC  handle  will  be  assigned. 

(1)  The  name  of  the  top-level  domain  to  join. 

For  example:  COM 

(2)  The  NIC  handle  of  the  administrative  head  of  the  organization. 

.11 ternately,  the  person's  name,  title,  mailing  address,  phone  number, 
r  ga.tizat  ion,  and  network  .mailbox.  This  is  the  contact  point  for 
.  r.  i  St  r  at  ive  and  policy  questions  about  the  domain.  In  the  case  of 
n  research  project,  this  should  be  the  principal  investigator. 

For  example: 


Administrator 


Crganizat ion 

Name 

Title 

Mail  Address 


Phone  Number 
Net  Mailbox 
NIC  Handle 


The  NetWorthy  Corporation 
Penelope  Q.  Sassafrass 
President 

The  NetWorthy  Corporation 

4676  Andrews  Way,  Suite  100 

Santa  Clara,  CA  94302-1212 

(415)  123-4567 

Sassa  f  rass’3ECHO  .  TNC  .  COM 

PQS 


(3)  The  NIC  handle  of  the  technical  contact  for  the  dom>ain. 
Alternately,  the  person's  name,  title,  mailing  address,  phone  number, 
o  r  gan  i  za  t  i  o.t,  and  network  mailbox.  This  is  the  contact  point  for 
prcblerns  concerning  the  domiain  or  zo.ne,  as  well  as  for  updating 
l.u  f  ,  rrr.at  io.n  about  the  do.m:ain  or  zone. 
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For  example : 


Technical  and  Zone  Contact 


Organization 

Name 

Title 

Mail  Address 


Phone  Number 
Net  Mailbox 
NIC  Handle 


The  NetWorthy  Corporation 
Ansel  A.  Aardvark 
Executive  Director 
The  NetWorthy  Corporation 
<5676  Andrews  Way,  Suite  100 
Santa  Clara,  CA .  94302-1212 
(415)  123-6789 
Aardvark@ECHO . TNC . COM 
AAA2 


v4)  The  name  of  the  domain  (up  to  12  characters)  .  This  is  the  nam.e 
that  will  be  used  in  tables  and  lists  associating  the  domain  with  the 
,i;rr.atn  server  addresses.  [While,  from  a  technical  standpoint,  domain 
n  be  quite  long  (programmiers  beware)  ,  shorter  names  are 
or  people  to  cope  with.] 

F  o  r  e  X  a  rr.p  1  e  :  T  N'C 

(5)  A  description  of  the  servers  that  provide  the  domain  service  for 
translating  names  to  addresses  for  hosts  in  this  domain,  and  the  date 
they  will  be  operational. 

A  good  way  to  answer  this  question  is  to  say  "Our  server  is 
supplied  by  person  or  com.pany  X  and  does  whatever  their  standard 
issue  server  does." 

For  exam^pie;  Our  server  is  a  copy  of  the  one  operated  by 
the  NIC;  it  will  be  installed  and  m.ade  operational  on 
1  Nove.Tiber  1987. 

(6)  Dt.mains  must  provide  at  least  two  independent  servers  for  the 
dom.ain .  Establishing  the  servers  in  physically  separate  locations 
an  1  on  different  PSNs  is  stro.ngly  recom,Tiended .  A  description  of  the 
server  m.achine  and  its  backup,  including 
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(a)  Hardware  and  software  (usinq  keywords  from  the  Assigned 
NomiDers  RFC)  . 

(b)  Host  domain  name  and  network  addresses  (which  host  on  which 
network  for  each  connected  network)  . 

(c)  Any  domain-style  nicknames  (please  limit  your  aoma in-style 
nicknam.e  request  to  one) 

For  example: 

-  Hardware  and  software 

VAX-11/750  and  UNIX,  or 
IBM-PC  and  MS-DOS,  or 

DEC-1090  and  TOPS-20 

-  Host  domain  names  and  network  addresses 

BAR.FOO.COM  10.9.0.193  on  ARPANET 

-  Domain-style  nickname 

BR.FOO.COM  (same  as  BAR.FOO.COM  10.9.0.13  on  ARPANET) 

■)  Planned  mapping  of  names  of  any  other  network  hosts,  other  than 
•-.-.e  server  machines,  into  the  new  domain's  naming  space. 

For  example: 

3AR-F002 . ARPA  (10.8.0.193)  ->  F002.BAR.COM 
BAR-F003 . ARPA  (10.7.0.193)  ->  F003 . BAR . COM 
BAR-F004 , ARPA  (10.6.0.193)  ->  F004.BAR.COM 


(3)  An  estimate  of  the  numloer  of  hosts  that  will  be  in  the  domain. 

(a)  Initially 

(b)  Within  one  year 

(c)  Two  years 

(d)  Five  years . 

For  example: 


(a ) 

Init 

:  iaily 

50 

(b) 

One 

year 

100 

(c) 

Two 

years 

200 

(d) 

Five  years  = 

500 

[  Page  1 2 ] 


Domain  Administrators  Guide 


RFC  1032 


RFC  1032  DOMAIN  ADMINISTRATORS  GUIDE  November  190/ 


(9)  The  date  you  expect  the  fully  qualified  domain  name  to  become 
the  official  host  name  in  HOSTS.TXT. 

Please  note:  If  changing  to  a  fully  qualified  domain  name  (e.g., 
FQO.BAR.CGM)  causes  a  change  in  the  official  host  name  of  an 
ARPANET  or  MILNET  host,  DCA  approval  must  be  obtained  beforehand. 
Allow  10  working  days  for  your  requested  changes  to  be  processed. 

ARPA.NET  sites  should  contact  ARPANETMGR@DDN1  .  ARPA .  MILNET  sites 
should  contact.  HOSTMASTER@SRI-NIC .  ARPA,  80  0-235-3155,  for 
further  instructions. 

(10)  Please  describe  your  organization  briefly. 

For  example:  The  NetWorthy  Corporation  is  a  consulting 
organization  of  people  working  with  UNIX  and  the  C  language  in  an 
electronic  networking  environment.  It  sponsors  two  technical 
conferences  annually  and  distributes  a  bimonthly  newsletter. 


This  example  of  a  completed  application  corresponds  to  the  examples 
found  in  the  companion  document  RFC-1033,  "Domain  Administrators 
Operations  Guide." 

(1)  The  name  of  the  top-level  domain  to  join. 

COM 

(2)  The  NIC  handle  of  the  administrative  contact  person. 

NIC  Handle  JAKE 

(3)  The  NIC  handle  of  the  domain's  technical  and  zone 

contact  person. 

MIC  Handle  DLEf 

(4)  The  naiTie  of  the  domain. 


(5)  h  de.scription  of  the  servers. 

Our  server  is  t.he  TOPS20  server  JEEVES  supplied  by  ISI;  it 
will  be  installed  and  made  operational  on  1  July  1987. 
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(6)  A  description  of  the  server  machine  and  its  backup: 

(a)  Hardware  and  software 

DEC-1090T  and  TOPS20 
DEC-2065  and  TOPS20 

(b)  Host  domain  name  and  network  address 

KL.SRI.COM  10.1.0.2  on  A.RPANET,  12  8.18.10.6  on  SRINET 
STRIPE.SRI.COM  10.4.0.2  on  ARPANET,  128.18.10.4  on  SRINET 

(c)  Domain-style  nickname 
None 

(7)  Planned  mapping  of  names  of  any  other  network  ho.sts,  other  than 
the  server  machines,  into  the  new  domain's  naming  space. 

SRI-Black jack . ARPA  (128.18.2.1)  ->  Blackjack.SRI.COM 
SRI-CSL.ARPA  (192.12.33.2)  ->  CSL.SRI.COM 

(8)  An  estimate  of  the  number  of  hosts  that  will  be  directly  within 


domain . 

(a) 

Initially 

50 

(b) 

One  year  = 

100 

(c) 

Two  years  = 

200 

(d) 

Five  years  = 

500 

(j)  A  date  when  you  expect  the  fully  qualified  domain  name  to  become 
the  official  host  name  in  HOSTS.TXT. 

31  September  1987 

(10)  Brief  description  of  organization. 

SRI  International  is  an  independent,  nonprofit,  scientific 
research  organization.  It  performs  basic  and  applied  research 
for  government  and  commercial  clients,  and  contributes  to 
worldwide  economic,  scientific,  industrial,  and  social  progress 
through  research  and  related  services. 
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DOMAIN  ADMINISTRATORS  OPERATIONS  GUIDE 


STATUS  OF  THIS  MEMO 

This  RFC  provides  guidelines  for  domain  administrators  in  operating  a 
domain  server  and  maintaining  their  portion  of  the  hierarchical 
database.  Familiarity  with  the  domain  system  is  assumed. 

Distribution  of  this  memo  is  unlimited. 

AC.KNOWLEDGMENTS 

This  memo  is  a  formiatted  collection  of  notes  and  excerpts  from  the 
references  listed  at  the  end  of  this  document.  Of  particular  mention 
are  Paul  Mockapetris  and  Kevin  Dunlap. 

INTRODUCTION 


A  dom.ain  server  requires  a  few  files  to  get  st 
normally  have  some  number  of  boot/startup  file 
"safety  belt"  files)  .  One  section  will  contai 
root  servers  that  the  server  will  use  to  find 
root  servers.  Another  section  will  list  the  z 
into  the  server  for  your  local  domain  informat 
typically  contains  all  the  data  for  a  particul 
describes  the  data  formats  that  can  be  used  in 
suggested  parameters  to  use  for  certain  fields 
attempting  to  do  anything  advanced  or  tricky, 
domain  RFC' s  for  more  details. 


arted.  It  will 
s  (also  known  as  the 
n  a  list  of  possible 
the  up-to-date  list  of 
one  files  to  be  loaded 
ion.  A  zone  file 
ar  domain.  This  guide 
zone  files  and 
.  If  you  are 
consult  the  appropriate 


Note:  Each  implementation  of  domain  software  may  require  different 

files.  Zone  files  are  standardized  but  some  servers  may  require 
other  startup  files.  See  the  appropriate  documentation  that  comes 
with  your  software.  See  the  appendix  for  some  specific  examples. 


ZONES 


A  zone  defines  the  contents  of  a  contiguous  section  of  the  domain 
space,  usually  bounded  by  administrative  boundaries.  There  will 
typically  be  a  separate  data  file  for  each  zone.  The  data  contained 
in  a  zone  file  is  composed  of  entries  called  Resource  Records  (RRs) . 
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You  may  only  put  data  in  your  domain  server  that  you  are 
authoritative  for.  You  must  not  add  entries  for  domains  other  than 
your  own  (except  for  the  special  case  of  "glue  records") . 

A  domain  server  will  probably  read  a  file  on  start-up  that  lists  the 
zones  it  should  load  into  its  database.  The  format  of  this  file  is 
not  standardized  and  is  different  for  most  domain  server 
irr.plementat  ions  .  For  each  zone  it  will  normially  contain  the  domain 
name  of  the  zone  and  the  file  name  that  contains  the  data  to  load  for 
the  zone. 

ROOT  SERVERS 

A  resolver  will  need  to  find  the  root  servers  when  it  first  starts. 
When  the  resolver  boots,  it  will  typically  read  a  list  of  possible 
root  servers  from  a  file. 

The  resolver  will  cycle  through  the  list  trying  to  contact  each  one. 
Whe.n  it  finds  a  root  server,  it  will  aslc  it  for  the  current  list  of 
root  servers.  It  will  then  discard  the  list  of  root  servers  it  read 
from  the  data  file  and  replace  it  with  the  current  list  it  received. 

Root  servers  will  not  change  very  often.  You  can  get  the  names  of 
currs.nt  root  server.s  from  the  NIC. 

FTP  the  file  NETINFO : ROOT-SERVERS . TXT  or  send  a  mail  request  to 
.hICSSRI-NIC  .ARPA. 


As  of  this  date  (June  1937)  they  are: 


SRI-NIC.ARPA 
C . ISI.EDU 
BRL-AOS . ARPA 
A . I S  r . EDU 


10.0.0.51  26.0.0.73 

10.0.0.52 

192.5.25.82  192.5.22.82  128.20.1.2 

26.3.0.103 


RESOURCE  RECORDS 


Records  in  the  zone  data  files  are  called  resource  records  (RRs) . 

They  are  specified  in  RFC-883  and  RFC-973.  An  RR  has  a  standard 
form, at  as  s.hown; 

<narrie>  [<ttl>]  [<class>]  <type>  <data> 

The  record  is  divided  into  fields  which  are  separated  by  white  space. 
<name> 

The  name  field  defines  what  domain  name  applies  to  the  given 
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RR.  In  som  cases  the  na'^.e  field  can  be  left  blank,  and  it  will 
default  to  che  name  field  of  the  previous  RR. 

<ttl> 

TTL  stands  for  Time  To  Live.  It  specifies  how  long  a  domain 
resolver  should  cache  the  RR  before  it  throws  it  out  and  asks  a 
domain  server  again.  See  the  section  on  TTL' s .  If  you  leave 
the  TTL  field  blank  it  will  default  to  the  minimum  time 
specified  in  the  SOA  record  (described  later) . 

<  c  1  a  s  s  > 


The  class  field  specifies  the  protocol  group.  If  left  blank  it 
will  default  to  the  last  class  specified. 


<type> 

The  type  field  specifies  what  type  of  data  i  in  the  RR.  See 
the  section  on  types. 

<data> 


The  data 

^  e  - 


field  is  defined  differently  for  each  type  and  class 
Popular  RR  data  formats  are  described  later. 


The  dc.m.ai.n  sysce.m  d 
resource  records, 
a  certain  order  doe 


oes  not  guarantee  to  preserve 
Listing  RRs  (such  as  multiple 
3  not  guarantee  they  will  be 


the  order  of 
address  records) 
used  in  that  order 


in 


Case  is  preserved  in  names  and  data  fields  when  loaded  into  the  name 
server.  All  comparisons  and  lookups  in  the  name  server  are  case 
insensitive . 

Parenthesis  are  used  to  group  data  that  crosses  a  line 

boundary. 

A  semicolon  (";")  starts  a  comment;  the  remainder  of  the  line  is 
ignored . 

The  asterisk  ("*")  is  used  for  wildcarding. 

The  at-sign  {"@")  denotes  the  current  default  domain  name. 
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NAMES 

A  domain  name  is  a  sequence  of  labels  separated  by  dots. 

Domain  names  in  the  zone  files  can  be  one  of  two  types,  either 
absolute  or  relative.  An  absolute  name  is  the  fully  qualified  domain 
name  and  is  terminated  with  a  period.  A  relative  name  does  not 
terminate  with  a  period,  and  the  current  default  domain  is  appended 
to  it  The  default  domain  is  usually  the  name  of  the  domain  That  was 
specified  in  the  boot  file  that  loads  each  zone. 

The  dom.ain  system  allows  a  label  to  contain  any  8-bit  character. 
Although  the  domain  system  has  no  restrictions,  other  protocols  such 
as  SMTP  do  have  name  restrictions.  Because  of  other  protocol 
restrictions,  only  the  following  characters  are  recomirtended  for  use 
in  a  host  narr;e  (besides  the  dot  separator)  : 

"A-Z",  "a-z",  "0-9",  dash  and  underscore 

TTL's  (Time  To  Live) 

It  is  important  that  TTLs  are  set  to  appropriate  values.  The  TTL  is 
the  timiS  (in  seconds)  that  a  resolver  will  use  the  data  it  got  from 
youi  server  before  it  asks  your  server  again.  if  you  set  the  value 
“00  low,  your  .server  will  get  loaded  down  with  lots  of  repeat 
-quests.  If  you  set  it  too  high,  then  information  you  change  will 
.not  get  distributed  in  a  reasonable  amount  of  time.  If  you  leave  the 
TTL  field  blank,  it  will  default  to  what  is  specified  in  the  SOA 
record  for  the  zone. 

Most  host  information  does  not  change  much  over  long  time  periods.  A 
gcod  way  to  set  up  your  TTLs  would  be  to  set  them  at  a  high  value, 
and  the.n  lower  the  value  if  you  know  a  change  will  be  coming  soon. 

You  might  set  most  TTLs  to  anywhere  between  a  day  (86400)  and  a  week 
(6C4800)  .  Then,  if  you  know  some  data  will  be  changing  in  the  near 
future,  set  the  TTL  for  that  RR  down  to  a  lower  value  (an  h"ur  to  a 
day)  until  the  change  takes  place,  and  then  put  it  back  up  to  its 
previous  value. 

Also,  all  RRs  with  the  same  namie,  class,  and  type  should  have  the 
same  TTL  value. 


The  do.main  system  was  designed  to  be  protocol  independent.  The  class 
field  is  used  to  identify  the  protocol  group  that  each  RR  is  in. 

The  cla.33  of  interest  to  people  using  TCP/IP  software  is  the  class 
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"Internet".  Its  standard  designation  is  "IN". 

A  zone  file  should  only  contain  RRs  of  the  sa.me  class. 

TYPES 

There  are  many  defined  RR  types.  For  a  complete  list,  see  the  dom.ain 
specification  RFCs .  Here  is  a  list  of  current  commonly  used  types. 
The  data  for  each  type  is  described  in  the  data  section. 


Designation  Description 


SOA 

Start  Of  Authority 

NS 

Nam.e  Server 

A 

Internet  Address 

CNA.ME 

Canonical  Name  (niclcname  pointer) 

HINFO 

Host  Inform.ation 

WKS 

Well  K.nown  Services 

MX 

Mail  Exchanger 

PTR 

Pointer 

SCA  (Start  Of  Authority) 

<name>  [<ttl>]  [<class>]  SOA  <origin>  <person>  ( 
<serial> 

<ref resh> 

<retry> 

<expire> 

<minimum>  ) 

The  Start  Of  Authority  record  designates  the  start  of  a  zone.  The 
zone  ends  at  the  next  SOA  record. 

<na.me>  is  the  name  of  the  zone. 

<origin>  is  the  name  of  the  host  on  which  the  master  zune  file 
resides . 

<person>  is  a  mailbox  for  the  person  responsible  for  the  zone.  It  is 
formatted  lii<e  a  mailing  address  but  the  at-sign  that  normally 
separates  the  user  from  the  host  name  is  replaced  with  a  dot. 

<serial>  is  the  version  number  of  the  zone  file.  It  should  be 
inc  rerr,e:;ted  anytime  a  change  is  made  to  data  in  the  zone. 


Dot  tor 
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<refre3;.>  is  how  long,  in  seconds,  a  secondary  r.an.e  server  is  to 
check  with  the  prirr.ary  r.arr.e  server  to  see  if  an  update  is  needed.  A 
good  value  here  would  be  one  hour  (3cCC)  . 


<retry>  is  how  long,  in  seconds,  a  .secondary  nonne  server  is  to  retry 
after  a  failure  to  ch;eck  for  a  refresh.  A  good  value  here  would  be 
1  3  rr’.inutes  (600)  . 

<expire>  is  the  upper  limit,  in  seconds,  that  a  secondary  .name  server 
is  to  use  the  data  before  it  expires  for  lack  of  getting  a  refresh. 
y?u  want  this  to  be  rather  largo,  and  a  nice  value  is  3600C00,  about 
42  days . 


<mi.ni.mu.m>  is  the  mi.nimum  number  of  seconds  to  be  used  for  TTL  values 
in  RRs .  A  minimum  of  at  least  a  day  is  a  good  value  here  (86400) . 


There  should  only  be  one  SOA  record  per  zone.  A  sample  SOA  record 
would  look  something  like: 


a  IN  SOA 


SRI-NIC . 
45 

3600 

600 

3600000 
864C0  ) 


ARPA.  HOSTMASTER. SRI 
; serial 
; refresh 
; retry 
;  e:-;pire 
/minimum 


-NIC. ARP A. 


( 


(Narr.e  Server) 

<domain>  [<ttl>]  [<class>]  NS  <server> 

T.no  NS  record  lists  the  name  of  a  machine  that  provides  domain 
service  for  a  particular  domain.  The  name  associated  with  the  RR  is 
the  domain  na.me  and  the  data  portion  is  the  name  of  a  host  that 
provides  the  service.  If  machines  SRI-NIC. ARPA  and  C. ISI.EDU  provide 
natie  lookup  service  for  the  domain  COM  then  the  following  entries 
wool  Id  be  used: 

COM.  NS  SRI-NIC. ARPA. 

NS  C. I3I.EDU. 

N'ote  that  the  machines  providing  name  service  do  not  have  to  live  in 
the  named  domain.  There  should  be  one  NS  record  for  each  server  for 
d  do.main.  Also  note  that  the  name  "COM"  defaults  .‘'or  the  second  NS 
r  e  0  o  r  d  . 

NS  records  for  a  domain  exist  in  both  the  zone  t.hat  delegates  the 
domain,  and  in  the  domain  itself. 
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GLUE  RECCRJl'S 

If  the  name  server  host  for  a  particular  domain  is  itself  inside  the 
domain,  then  a  'glue'  record  will  be  needed.  A  glue  record  is  an  A 
(address)  RR  that  specifies  the  address  or  the  server.  Glue  records 
are  only  needed  in  the  server  delegating  the  dontain,  not  in  the 
domiain  itself.  If  for  e.xample  the  namie  server  for  domain  SRI.COM  was 
KL .  SRI  .  CO.M,  then  the  NS  record  would  look  like  this,  but  you  will 
also  need  to  have  the  following  A  record. 

SRI. COM.  NS  KL.SRI.COM. 

KL.SRI.COM.  A  10.1.0.2 


A  (Address) 

<host>  [<ttl>j  i<class>]  A  <address> 

he  data  for  an  A  record  is  an  internet  address  in  dotted  decim.al 
or-m,.  A  sa.mple  .A  record  m.ight  look  like; 

SRI-NIC  ..ARPA.  A  10.0.0.51 

There  should  be  one  A  record  for  each  address  of  a  host. 

iME  (  Carionicai  .N’a.me) 

<nickt.ame>  [<ttl>]  [<class>]  CNAME  <host> 

The  CNAJKE  record  is  used  for  nicknames.  The  name  associated  with  the 
RR  is  the  nickname.  The  da^a  portion  is  the  official  name.  For 
example,  a  m.achine  named  SRI-NIC. ARPA  may  want  to  have  the  nickname 
•NIC.  ARPA.  In  that  case,  the  following  RR  would  be  used: 

NIC . ARPA .  CNAMC  SRI -NIC . ARPA . 

There  must  not  be  ar.y  ether  RRs  associated  with  a  nickname  of  the 
3  <3  C  -L  <2  s  s  . 

Nicknames  ai-e  also  useful  when  a  host  changes  it's  name.  In  that 
case,  it  is  us oi  1 ly  a  good  idea  to  have  a  CKAHE  pointer  so  that 
people  ctiil  using  the  old  name  will  get  to  the  right  place. 
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its  mail  to  be  delivered 
use  the  MX  record: 


the  host 


r  .  r  O  '. 


5AZ  . : 


y.  .may  wan 


mail  to  be  delivered  to  one  of  three 


rr.ac.n  rnes , 
’.Z  .rOC  .C'oM. 


:ne  roixcwing  orae! 


MX 

MX 

MX 


10  F01.FOO.COM. 
20  F02.FOO.COM. 
30  FC3.FCQ.COM. 


ire  domain  cf  hosts  not  connected  to  the  Internet  may  want 
mail  to  go  through  a  mail  gateway  that  k.nows  how  to  deliver 
:  tnem..  If  thev  would  like  mail  addressed  to  anv  host  in  the 


MX 

MX 


:he  mail  gateway  they  mighi.  use  : 

10  BEL.AY.CS.NET. 

20  RELAY.CS.NET. 


a  r.  y  t  n  r 
-ALDR.P 


hat  you  can  specify  a  wildcard  in  t.he  .MX  record  to  match  on 
r.q  in  FOo.COM,  but  that  it  won't  match  a  plain  F00.COM. 


The  structure  of  names  in  the  domain  system  is  set  up  in  a 
re  r  a  r  i  oa  ^  way  such  ttiat  the  address  of  a  na.r.e  can  be  found  by 
tracing  down  the  dc.main  tree  contacting  a  server  for  each  label  of 
tr.fe  r.a.me.  Because  of  this  'indexing'  based  cn  name,  there  is  no  easy 
v;;-.'.’  tc  "'ranslate  a  host  address  back  into  its  host  name. 


reverse  translation  easily,  a  domain  was  created 
iresses  as  part  of  a  na.mie  that  then  points  to  the 
I.n  this  way,  there  is  now  an  'index'  to  hosts' 
iddress.  This  aadress  mapping  domain  is  called 
.,n  that  domain  are  subdomains  for  each  network, 
rber.  Also,  for  consistency  and  natural 
rets  of  a  host  number  are  reversed. 


:arrpie,  the  ARFA1;ET 
,  :  0  .  IN'-AXOR  .  AREA  . 

1  0  .  :n-alxr  that  c-- 


X  R 
i  .3 


n 


is 

net  10. 

That 

] 

w: 

t 

h i n  this 

doma 

ii 

in 

t 

s  to  the 

RRs 

f' 

bl 

) 

Since 

the 

I'i 

3 ) 

, 

there  is 

1  als 

c 

th 

e 

same  RR' 

s  f  o 

r 

i 

3 

def inea 

belo 

w 

means  there  is  a  domain 
n  there  is  a  PTR  RR  at 
or  the  host  SRI-I-'IC  .  ARPA 
IC  is  also  on  the  MILNET 
a  PTR  RR  at  7 3 . 0 . 0 . 2 6 . IN- 
SRI  -NIC  .  ARPA  .  The  for.mat 
along  with  the  examples 
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/t^rrx^e  r 


.  1  >  '  "  <  .r  1 8  3  s  ^  £ 'r  F 


sor?.e  o*:ner 


rV  o  i.  t£. 


d  .L  o  ti  o 


r .  8  rr.tj  s  3  li 


■  „  a  i  ^  a  o  “cr  o  . 


w i cn  adiiressos 


.‘J-Ad  T'R  .  ARP/-. .  PTR  £R.I -NIC  . /■.RPA  . 


:CK  tree  is  a. so  esed  to  locate  gateways  c  ;a  a  particular 
Gateways  have  the  sarte  kind  of  PTR  RRs  as  hosts  (as 
idition  ^'r.ey  h=>ve  other  PTRs  used  to  *ccate  therr.  by  networ 
one.  These  records  have  only  1,  2,  or  3  octets  as  part  c 
depending  on  whether  they  are  class  A,  R,  or  C  networf;s, 


i  the  SRI-GSL  gateway  for  example.  It  co: 

cne  cla;35  .A,  one  class  B  and  one  class  ; 
PR's  for  a  host  in  the  CSL.SRI.COM  zone: 


:ts  3  different 


.  0 . 2 . 0 . 2 
12S  .  13.1.1 
192.12.33.; 


3  different  zones  (one  for  each  network),  it  wii 
llcwir.cf  r.urrTder  tc  r.arne  t  rans  1  at.  ion  poir.t6r3: 

.  ;  .  2  .  10  .  IN-AX>0P  .  ARPA  .  PT’’,  GW  ,  CSL  .  SRI  .  COM  . 

.  1  .  1  3  .  12  8  .  IN-ADOR  .  AR.FA  .  PTR  GW  .  CSL  .  SRI  .  CC.M  . 

.  33  .  12  .  192  .  Iii-AD0R.A?.?A.  PTR  GW. CSL. SRI  .COM. 


the  sa.T.e  3  zones  will  be  one  of  the  follcwi: 


;  a  1 1  o  n  p  o :  n  t  e  r  s  : 
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Adding  a  subdomain. 

To  add  a  new  subdorriai.n  to  your  domain: 

Setup  the  other  domain  server  and./cr  the  new  zone  file. 

Add  an  NS  record  for  each  server  of  the  new  domain  to  the  zone 
file  of  the  parent  domain. 

Add  any  necessary  glue  RRs . 

Adding  a  host . 

To  add  a  new  host  to  your  zone  files: 

Edit  the  appropriate  zone  file  for  the  domain  the  host  is  in. 

Add  an  entry  for  each  address  of  the  host. 

Optionally  add  CNAKE,  HINFO,  WKS,  and  MX  records. 

Add  the  reverse  IN-ADDR  entry  for  each  host  address  in  the 
appropriate  zone  files  for  each  network  the  host  in  on. 

Deleting  a  host. 

To  delete  a  host  from  the  zone  files: 

Remove  all  the  hosts'  resource  records  from  the  zone  file  of 
the  domain  the  host  is  in. 

Remove  all  the  hosts'  PTR  records  from  the  IN-ADDR  zone  files 
for  each  network  the  host  was  on. 

Adding  gateways. 

Follow  instructions  for  adding  a  host. 

Add  ti  e  gateway  location  PTR  records  for  each  network  the 
gatewc  y  is  on . 

Do.''etir.g  gateways. 

Follow  instructions  for  deleting  a  nost . 

Also  delete  the  gateway  location  PTR  records  for  each  network 

or  [Page  11] 
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'X.i.MFLE  DCIO^aIN  SERVER  DATABASE  FILES 

The  following  exan.ples  show  how  zone  files  are  set  up  for  a  typical 
organization.  SRI  will  be  used  as  the  example  organization.  SRI  has 
decided  to  divided  their  domain  SRI.COM  into  a  few  subdomains,  one 
for  each  group  that  wants  one.  The  subc.c  .lains  are  CsL  and  ISTC. 

Note  the  following  interesting  items: 

There  are  both  hosts  and  domains  under  SRI.COM. 

CSL.SRI.COM  is  both  a  domain  name  and  a  host  name. 

.All  the  domains  are  serviced  by  the  sam.e  pair  of  domain  servers. 

All  hosts  at  SRI  are  on  net  128.18  except  hosts  in  the  CSL  domain 
which  are  on  net  192.12.33.  Note  that  a  domain  does  not  have  to 
ccrresficnd  to  a  physical  network.. 

The  examples  do  not  necessarily  correspond  to  actual  data  in  use 
by  the  SRI  domain. 

SRI  Domain  Organization 

+ - + 

I  COM  I 
+ - + 


Hosts 


Hosts  I 


Hosts 
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OO’T .  SERVERS"  .  Again,  the  format  of  this  file  is  not 
i  zed .  1 


■*ist  oi  possible  root  servers 

.  ARPA  10.0.0.51  26.0.0.73 

;.  I  SI.EDU  10.0.0.52 

SRU-ADS.ARPA  192.5.25.82  192.5.22.82  128.20.1 

A.ISI.EDU  26.3.0.103 
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[File  "SRI. ZONE"] 

SRI.COM.  IN  ;>OA  KL.SRI.COM  DLE.STRIPE.SRI.COM.  ( 

870407  .-serial 

1800  ; refresh  every  30  minutes 

600  .-retry  every  10  minutes 

604800  .-expire  after  a  week 

85400  .-default  of  an  hour 

) 

SRI.COM.  NS  KL.SKI.COM. 

NS  STRIFE.SRI.COM. 

MX  10  KL.SRI.COM. 

; SRI. COM  hosts 

KL  A  10.1.0.2 

a  128.18  .10.6 

MX  10  KL.SRI.COM. 

TRIPE  A  10.4.0.2 

TRIPE  A  128.18.10.4 

MX  10  STRIPE  .  SP.I  .CO.M. 

NIC  CNAME  SRI-NIC . ARPA. 

Blackjack  A  128.18.2.1 

HINFO  VAX-11/780  UNIX 

WKS  128.18.2.1  TCP  TELNET  FTP 

C3L  A  192.12.33.2 

HINFO  FOONLY-F4  TOPS20 

WKS  192.12.33.2  TCP  TELNET  FTP  SMTP  FINGER 

MX  10  CSL.SRI.COM. 


'.ottor 
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[File  "CSL.ZONE"] 


CSL.SR-.COM.  I N 

SOA  KL.SRI. 

.COM.  DLE.STRIPE.SRI.COM.  ( 

870330 

; serial 

1800 

.•refresh  every  30  minutes 

600 

; retry  every  10  minutes 

604800 

; expire  after  a  week 

86400 

) 

.•default  of  a  day 

CSL -  SR  T . COM .  NS 

KL.SRI , 

.COM. 

NS 

STRIPE 

.  SRI .COM. 

A 

192.12, 

.33.2 

■•CSL.SRI  .COM  ho.sts 

A  CNAME 

CSL.SRI.COM. 

B  A 

192.12.33.3 

H I K  F  0 

FOONLY-F4 

TOP  32 0 

WKS 

192 .12.33.3 

TCP  TELNET  FTP  SMTP 

GW  A 

10.2.11.2 

A 

192 . 12 . 33 . 1 

A 

128.18.1.1 

HINFO 

PDP-11/23 

MOS 

SMELLY  A 

192.12.33.4 

HINFO 

JMAGEN 

IMA3EN 

SQUIRREL  A 

192.12.33.5 

HINFO 

XEROX-1100 

INTERLISP 

VENUS  A 

192.12.33.7 

HINFO 

SYMBOLICS-3600 

LISPM 

HELIUM  A 

192.12.33.30 

HINFO 

SUN-3/16U 

UNIX 

ARGON  A 

192.12.33.31 

HINFO 

SUN-3/75 

UNIX 

RADON  A 

192.12.33.32 

HINFO 

SUN-3/75 

UNIX 

Do  tic 
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[File  "ISTC.ZONE"] 
ISTC.SRI.COM.  IN  SOA 


KL.SRI.COM.  roemers.JOYCE.ISTC.SRI.COM.  { 
870406  /serial 

1800  /refresh  every  30  minutes 

600  /retry  every  10  minutes 

604800  /expire  after  a  week 

86400  /default  of  a  day 


ISTC . SRI .COM. 

KS 

KL . SRI .COM . 

i'-'S 

STRIPS . 3RX . COM . 

MX 

10  SPACH.ISTC 

;  ISTC  hosts 

i  0  yce 

A 

128 .18.4.2 

HINFO 

VAX-1 1/7 50  UNIX 

b  Z  0 

A 

128.18.0.6 

HINFO 

SUN  UNIX 

sundae 

A 

128.18.0. 11 

HINFO 

SUN  UNIX 

1 3  0  a 

A 

128.18.0.201 

A 

1  0  .  3  .  C  .  2 

HINFO 

VAX-11  /750  '.'NIX 

MX 

10  T3CA.ISrc.SRI.COM. 

S  0 

CN.AME 

tsca 

p  r  rr,/'. 

A 

128  .18.0 .203 

A 

1  0  .  2  .  C  .  5 1 

H  I  0 

POP-:  1/44  UNIX 

.  'S.  i!'  . 

A 

123.18.4.3 

10.2 . C . 107 

Hir;FO 

VAX- 1 1 ' 7 8 0  UNIX 

1  0  3? A..M  .  ISTC  .  S?  I  .  CO.M  . 
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SGA  KL , 

.SRI .COM 

DLE . STRIPE . SRI . COM 

87  0  4  0  6 

; serial 

1300 

; refresh 

every  30  minu^es 

600 

/retry  every  10  minutes 

6  0  4  8  C  0 

; expire 

after  a  v;eek 

86400 

;  de  f  a  1 1 

of  a  day 

) 


13  .  128  .  IN-ArZ'R.  ARFA.  NS  KL. SRI. COM. 

NS  STR.IPE  .  SRI  .  COM  . 

P'-R  G'W.CSL.SRI  .COM. 

;  SPINET  [128  18.0.0]  Address  Translations 

;  S. RI.COM  Hosts 


1.2.18.1 

28 . IN-ADDR . ARPA . 

PTR 

Blackjack . SRI . COM. 

;  ISTC.S 
2.4.18.1 

RI . COM  Hosts 

23 . IN-ADDR. ARPA. 

PTR 

Joyce . ISTC. SRI .COM. 

6  .  C  .  1 8  .  1 

28 . IN-ADDR, ARPA. 

PTR 

bozo. ISTC. SRI .COM. 

1 1  .  C  .  1 8  . 

128 . IN-ADDR. ARPA. 

PTR 

sundae . ISTC . SRI . COM 

2  0  1  .  C  .  1 8 

. 128 . IN-ADDR. ARPA. 

PTR 

tsca  .  ISTC  .  SRI  .  CO.M  . 

2  C  3  .  0  .  1  8 

. ] 28 . IN-ADDR. ARPA. 

PTR 

prmh . ISTC . SRI .COM. 

3.4.18.1 

28 . IN-ADDR. ARPA. 

PTR 

spam. ISTC . SRI . COM . 

;  CSL .SR 
1.1.18.1 

1  .  CO.M  Hosts 

2  8  .  IN-AD’DR.ARPA. 

PTR 

GW. CSL. SRI .COM. 
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ributed  with  4.3  PSI 


specific  files;  the 
cptl'cic,  files,  and 
ee  the  Name  Server 


lly  Cdllod  "  car:  ed.  boot  "  .  This 
b"  in  tcv  exam, pie  section. 


pri:r.sry 

primary 


.'3D.  SRI  .  COM 
:3TC . SRI .cor 
.8.128. IN-ADDR . ARPA 
!3 . 12 . 192 . Ih-ADDR. ARPA 


nameci .  ca 

SRI . ZONE 

CSD . ZONE 

ISTC  .  ZONE 

SRINET . ZONE 

SBI-CSL-NET . ZONE 


nsually  ~alle:: 
iRv'ERS'*  in  t h'l 


" named . ca " . 
e.':a:.;ple  sect 


T'. .s 3  ID  le  rcct 


NS  SRI-Nl 
NS  C.l.ll. 
NS  ERL -AC 
NS  C.ISI. 
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MAIL  ROUTING  AND  THE  DOMAIN  SYSTEM 


Status  of  this  Memo 

This  RFC  presents  a  description  of  how  mail  systems  on  the  Internet 
are  expected  to  route  messages  based  on  information  from  the  domain 
system  described  in  RFCs  882,  883  and  973.  Distribution  of  this  memo 
is  unlimited. 

Introduction 

The  purpose  of  this  m.emo  is  to  explain  how  mailers  are  to  decide  how 
to  route  a  message  addressed  to  a  given  Internet  domain  name.  This 
involves  a  discussion  ir'-.crprot  MX  RRs,  which  oi-c  ..CcJ 

for  message  routing.  Note  that  this  memo  makes  no  statement  about 
how  mailers  are  to  deal  with  MB  and  MG  RRs,  which  are  used  for 
interpreting  mailbox  names. 

Under  RFC-882  and  RFC-883  certain  assumptions  about  mail  addresses 
have  been  changed.  Up  to  now,  one  could  usually  assume  that  if  a 
message  was  addressed  to  a  mailbox,  for  example,  at  LOKI.BBN.COM, 
that  one  could  just  open  an  SMTP  connection  to  LOKI.BBN.COM  and  pass 
the  message  along.  This  system  broke  down  in  certain  situations, 
such  as  for  certain  UUCP  and  CSNET  hosts  which  were  not  directly 
attached  to  the  Internet,  but  these  hosts  could  be  handled  as  special 
cases  in  configuration  files  (for  example,  most  mailers  were  set  up 
to  automatically  forward  mail  addressed  to  a  CSNET  host  to 
CSNET-RELAY. ARPA) . 

Under  domains,  one  cannot  simply  open  a  connection  to  LOKI.BBN.COM, 
but  must  instead  ask  the  domain  system  where  messages  to  LOKI.BBN.COM 
are  to  be  delivered.  And  the  domain  system  may  direct  a  mailer  to 
deliver  messages  to  an  entirely  different  host,  such  as  SH.CS.NET. 

Or,  in  a  more  complicated  case,  the  mailer  may  learn  that  it  has  a 
choice  of  routes  to  LOKI.BBN.COM.  This  memo  is  essentially  a  set  of 
guidelines  on  how  mailers  should  behave  in  this  more  complex  world. 

Readers  are  expected  to  be  familiar  with  RFCs  882,  883,  and  the 
updates  to  them  (e.g.,  RFC-973). 
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What  the  Domain  Servers  Know 

The  domain  servers  store  information  as  a  series  of  resource  records 
(RRs) ,  each  of  which  contains  a  particular  piece  of  inform, ation  about 
a  given  domain  name  (which  is  usually,  but  not  always,  a  host)  .  The 
sim.plest  way  to  thin)c  of  a  RR  is  as  a  typed  pair  of  datum,  a  domain 
name  matched  with  relevant  data,  and  stored  with  some  additional  type 
information  to  help  svstems  determine  when  the  RR  is  relevant.  For 
the  purposes  of  miessage  routing,  the  system  stores  RRs  known  as  MX 
RRs.  Each  MX  matches  a  domain  name  with  two  pieces  of  data,  a 
preference  value  (an  unsigned  16-bit  integer),  and  the  name  of  a 
host.  The  preference  number  is  used  to  indicate  in  what  order  the 
mailer  should  attempt  deliver  to  the  MX  hosts,  with  the  lowest 
numbered  MX  being  the  one  to  try  first.  Multiple  MXs  with  the  same 
preference  are  permitted  and  have  the  sam.c  priority. 

In  addition  to  mail  information,  the  servers  store  certain  other 
types  of  RR' s  which  mailers  may  encounter  or  choose  to  use.  These 
are:  the  canonical  name  (CNAME)  RR,  which  simply  states  that  the 
dti.'Viin  quoriod  f'  r  is  actually  an  alias  for  another  domain  name, 

which  is  the  proper,  or  canonical,  name;  and  the  Well  Known  Service 
(WK3)  RR,  which  stores  information  about  network  services  (such  as 
SMTP)  a  given  domain  name  supports. 

..rai  Routing  Guidelines 

Before  delving  into  a  detailed  discussion  of  how  mailers  are  expected 
to  do  m.ail  routing,  it  would  seem  to  make  sense  to  give  a  brief 
overview  of  how  this  memo  is  approaching  the  problems  that  routing 
pos  ;s  . 

The  first  m.ajor  principle  is  derived  from  the  definition  of  the 
preference  field  in  MX  records,  and  is  intended  tc  prevent  mail 
looping.  If  the  miailer  is  on  a  host  which  is  listed  as  an  MX  for  the 
destination  host,  the  mailer  may  only  deliver  to  an  MX  which  has  a 
lower  preference  count  than  its  own  host. 

It  is  also  possible  to  cause  mail  looping  because  routing  information 
is  out  of  date  or  incomplete.  Out  of  date  information  is  only  a 
problem  when  domain  tables  are  changed.  The  changes  will  not  be 
known  to  all  affected  hosts  until  their  resolver  caches  time  out. 
There  is  no  way  to  ensure  that  this  will  not  happen  short  of 
requiring  mailers  and  their  resolvers  to  always  send  their  queries  to 
an  authoritative  server,  and  never  use  data  stored  in  a  cache.  This 
is  an  impractical  solution,  since  eliminating  resolver  caching  would 
make  mailing  inordinately  expensive.  What  is  more,  the  out-of-date 
RR  problem  should  not  happen  if,  when  a  domain  table  is  changed. 


Partridge 


[Page  2] 


Mail  Routing  and  the  Domain  System 


RFC  974 


RFC  974  January  1986 

Mail  Routing  and  the  Doniair;  System 


affected  hosts  (those  in  the  list  of  MXs)  have  their  resolver  caches 
flushed.  In  other  words,  given  proper  precautions,  mail  looping  as  a 
result  of  domain  information  should  be  avoidable,  without  requiring 
mailers  to  query  authoritative  servers.  (The  appropriate  precaution 
is  to  chock  with  a  host's  administrator  before  adding  that  host  to  a 
list  of  MXs) . 

The  inco.mpiere  data  proble.m  also  requires  sene  care  when  handling 
domai.n  queries.  If  the  answer  section  of  a  query  is  incomplete 
critical  MX  RRs  may  be  left  out.  This  may  result  in  mail  looping,  or 
in  a  .message  being  mistakenly  labelled  undeliverable.  As  a  result, 
rr.ailers  .m.ay  only  accept  responses  from  the  do.m'.ain  system  which  have 
complete  answer  sections.  Note  that  this  entire  problem  can  be 
avoiaed  by  only  using  virtual  circuits  for  queries,  but  since  this 
situation  is  likely  to  be  very  rare  and  datagrams  are  the  preferred 
way  to  interact  with  the  domain  system,,  im.plementors  should  probably 
just  ensure  that  their  mailer  will  repeat  a  query  with  virtual 
circuits  should  the  truncation  bit  ever  he  set. 

Ceter.mdning  Where  to  Send  a  Message 

The  explanation  of  how  mailers  should  decide  how  to  route  a  message 
is  discussed  in  terms  of  the  problem  of  a  mailer  on  a  host  with 
do.T.ain  na.me  LOCAL  trying  to  dexiver  a  message  addressed  to  the  domain 
na.m.e  RE.MOTE .  Both  LOCAL  and  REMOTE  are  assu.m.ed  to  be  syntactically 
correct  do.main  nam.es.  Fu rtherm.ore,  LOCAL  is  assu.mied  to  be  the 
official  na.m.e  for  the  host  on  which  the  mailer  resides  (i.e.,  it  is 
not  a  alias)  . 

Issuing  a  Query 

The  first  step  for  the  rr,ailer  at  LOCAL  is  to  issue  a  query  for  MX  RRs 
for  REMOTE.  It  is  Strongly  urged  that  this  step  be  taken  every  time 
a  rr.ailer  attempts  to  send  the  message.  The  hope  is  that  changes  in 
the  dorr.ain  database  will  rapidly  be  used  by  mailers,  and  thus  domain 
acLm.inistrators  will  be  able  to  re-route  in-transit  messages  for 
defective  hosts  by  simply  changing  their  domain  databases. 

Certain  responses  to  the  query  are  cons.idered  errors: 

Getting  no  response  to  the  query.  Tli-  .ain  server  the  mailer 

queried  never  sends  anything  back.  (1  is  distinct  from  an 

answer  which  contains  no  answers  to  the  query,  which  is  not  an 
error)  . 

Getting  a  response  in  which  the  truncation  field  of  the  header  is 
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set.  (Recall  discussion  of  incomplete  queries  above) .  Mailers 
m.ay  not  use  responses  of  this  type,  and  should  repeat  the  query 
using  virtual  circuits  instead  of  datagrams. 

Getting  a  response  in  which  the  response  code  is  non-zero. 

Mailers  are  expected  to  do  something  reasonable  in  the  face  of  an 
error.  The  behaviour  for  each  type  of  error  is  not  specified  here, 
but  implementors  should  note  that  different  types  of  errors  should 
probably  be  treated  differently.  For  exam.ple,  a  response  code  of 
"non-existent  domain"  should  probably  cause  the  message  to  be 
returned  to  the  sender  as  invalid,  while  a  response  code  of  "server 
failure"  should  probably  cause  the  message  to  be  retried  later. 

There  is  one  other  special  case.  If  the  response  contains  ai,  answer 
which  is  a  Ch’A.ME  RR,  it  i.ndicates  that  REMOTE  is  actually  an  alias 
for  some  other  dc'r='''n  '^acie.  The  query  should  be  repeated  with  the 
canonical  do.m^ain  narr.e  . 

If  the  response  does  not  contain  c.n  error  response,  and  does  not 
contain  aliases,  its  answer  section  should  be  a  (possibly  zero 
length)  list  of  MX  RRs  for  domain  name  REMOTE  (or  REMOTE'S  true 
dortain  name  if  REMOTE  was  a  alias) .  The  next  section  describes  how 
this  list  is  interpreted. 

Interpreting  the  List  of  MX  RPs 

NOTE:  This  section  only  discusses  how  mailers  choose  which  names  to 
try  to  delive’'  a  message  to,  working  from  a  list  of  RR' s .  It  does 
n-^t  discuss  how  the  mailers  actually  make  delivery.  Where  ever 
delivering  a  m.essage  is  mentioned,  all  that  is  meant  is  that  the 
.mailer  should  do  whatever  it  needs  to  do  to  transfer  a  message  to  a 
re.mote  site,  given  a  domain  name  for  that  site.  (For  example,  an 
SMTP  mailer  will  try  to  get  an  addre.«s  for  the  domain  name,  which 
involves  another  query  to  the  domain  system,  and  then,  if  it  gets  an 
address,  connect  to  the  SMTP  TCP  port) .  The  mechanics  of  actually 
transferring  the  message  over  the  network  to  the  address  associated 
with  a  given  domain  name  is  not  within  the  scope  cf  this  memo. 

It  is  possible  that  the  list  of  MXs  in  the  response  to  the  query  will 
be  empty.  This  is  a  special  case.  If  the  list  is  empty,  mailers 
should  treat  it  as  if  it  contained  one  RR,  an  MX  RR  with  a  preference 
value  of  0,  and  a  host  name  of  REMOTE.  (I.e.,  REMOTE  is  its  only 
MX) .  In  addition,  the  mailer  should  do  no  further  processing  on  the 
list,  but  should  attempt  to  deliver  the  message  to  REMOTE.  The  idea 
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here  is  that  if  a  domain  fails  to  advertise  any  information  about  a 
particular  name  we  will  give  it  the  benefit  of  the  doubt  and  attempt 
delivery . 

If  the  list  is  not  empty,  the  mailer  should  remove  irrelevant  PR's 
from  the  list  according  to  the  following  steps.  Note  that  tlie  order 
is  significant. 

For  each  MX,  a  WKS  query  should  be  issued  to  see  if  the  domain 
name  listed  actually  supports  the  mail  service  desired.  MX  RRs 
which  list  domain  names  which  do  not  support  the  service  should  be 
discarded.  This  step  is  optional,  but  strongly  encouraged. 

If  the  domain  name  LOCAL  is  lis*'ed  as  an  MX  RR,  all  MX  RRs  with  a 
preference  value  greater  than  or  equal  to  that  of  LOCAL'S  must  be 
discarded . 

After  removing  irrelevant  RRs,  the  list  can  again  be  empty.  This  is 
now  an  error  condition  and  can  occur  in  several  ways.  The  simplest 
case  is  that  the  V<’KS  queries  have  discovered  that  none  of  the  hosts 
listed  supports  the  mail  service  desired.  The  message  is  thus  deemed 
undeliverable,  though  extremely  persistent  mail  systems  might  want  to 
t ry  a  delivery  to  REMOTE'S  address  (if  it  exists)  before  returning 
the  message.  Another,  more  dangerous,  possibility  is  that  the  domain 
system  believes  that  LOCAL  is  handling  message  for  REMOTE,  but  the 
m.ailer  on  LOCAL  is  not  set  up  to  handle  mail  for  REMOTE.  For 
example,  if  the  domain  system  lists  LOCAL  as  the  only  MX  for  REMOTE, 
LOCAL  will  delete  all  the  entries  in  the  list.  But  LOCAL  is 
presum.ably  querying  the  domain  system  because  it  didn't  Itnow  what  to 
do  with  a  message  addressed  to  REMOTE.  Clearly  something  is  wrong. 

How  a  mailer  chooses  to  handle  these  situations  is  to  some  extent 
implementation  dependent,  and  is  thus  left  to  the  implementor's 
discret ion . 

If  the  list  of  MX  RRs  is  not  em.pty,  the  mailer  should  try  to  deliver 
the  miessage  to  the  MXs  in  order  (lowest  preference  value  tried 
first)  .  The  m.ailer  is  required  to  attempt  delivery  to  the  lowest 
valued  MX.  Implemiento rs  are  encouraged  to  write  mailers  so  that  they 
try  the  MXs  in  order  until  one  of  the  MXs  accepts  the  message,  or  all 
the  Mas  have  been  tried.  A  somewhat  less  demanding  system,  in  which 
a  fi.xed  numJcer  of  MXs  is  tried,  is  also  reasonable.  Note  that 
multiple  MXs  may  have  the  same  preference  value.  In  this  case,  all 
MXs  at  with  a  given  value  must  be  tried  before  any  of  a  higher  value 
are  tried.  In  addition,  in  the  special  case  in  which  there  are 
several  MXs  with  the  lowest  preference  value,  all  of  them  should  be 
tried  before  a  message  is  deemed  undeliverable. 
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Minor  Special  Issues 

There  are  a  couple  of  special  issues  left  out  of  the  preceding 
section  because  they  complicated  the  discussion.  They  are  treated 
here  in  no  particular  order. 

Wildcard  names,  those  containing  the  character  in  them,  may  be 

used  for  mail  routing.  There  are  likely  to  be  servers  on  the  network 
which  simply  state  that  any  mail  to  a  domiain  is  to  be  routed  through 
a  relay.  For  example,  at  the  time  that  this  RFC  is  being  written,  all 
mail  to  hosts  in  the  domain  IL  is  routed  through  RELAY.CS.NET.  This 
is  done  >^y  o’-eating  a  wildcard  RR,  which  state.s  that  *.IL  has  an  MX 
of  RELAY . CS . NET .  This  should  be  transparent  to  the  mailer  since  the 
domain  servers  will  hide  this  wildcard  match.  (If  it  matches  * . IL 
with-  HUJI ,  IL  for  example,  a  dom.ain  server  will  return  an  RR 
containing  HUJI.IL,  not  *.IL).  If  by  sortie  accident  a  mailer  receives 
an  RR  with  a  wildcard  domain  name  in  its  name  or  data  section  it 
should  discard  the  RR . 

Note  that  the  algorithm  to  delete  irrelevant  RRs  breaks  if  LOCAL  has 
a  alias  and  the  alias  is  listed  in  the  MX  records  for  REMOTE.  (E.g. 
REMOTE  has  an  MX  of  ALIAS,  where  ALIAS  has  a  CNAME  of  LOCAL) .  This 
can  be  avoided  if  aliases  are  never  used  in  the  data  section  of  MX 
RRs  . 

Irr.ple.T.entors  should  understand  that  the  query  and  interpretation  of 
the  query  is  only  performed  for  REMOTE.  It  is  not  repeated  for  the 
MX  RRs  listed  for  REMOTE.  You  cannot  try  to  support  more  extravagant 
rra\l  routing  by  building  a  chain  of  MXs .  (E.g.  UNIX.BBN.COM  is  an  MX 

for  RELAY.CS.NET  and  RELAY.CS.NET  is  an  MX  for  all  the  hosts  in  .IL, 
tut  this  does  not  mean  that  UNIX.BBN.COM  accepts  any  responsibility 
for  rr.ail  for  .IL). 

Finally,  it  should  be  noted  that  this  is  a  standard  for  routing  on 
the  Internet.  Mailers  serving  hosts  which  lie  on  multiple  networks 
will  presumiably  have  to  make  some  decisions  about  which  network  to 
route  through.  This  decision  making  is  outside  the  scope  of  this 
memo,  although  mailers  may  well  use  the  domain  system  to  help  them 
decide.  However,  once  a  mailer  decides  to  deliver  a  message  via  the 
Internet  it  must  apply  these  rules  to  route  the  message. 
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Examples 

To  illustrate  the  discussion  above,  here  are  three  examples  of  how 
mailers  should  route  messages.  All  examples  work  with  the  following 
aatabase : 

A. EXAMPLE .ORG  IN  MX  10  A . EXAMPLE . ORG 

A. EXAMPLE.ORG  IN  MX  15  B . EXAMPLE . ORG 

A. EXAMPLE. ORG  IN  MX  20  C . EXAMPLE . ORG 

A.  EXA.MPLE.ORG  IN  WKS  10.0.0.1  TCP  SMTP 

B.  EXAMP LE.ORG  IN  MX  0  B . EXAMPLE . ORG 

B. EXAMP LE.ORG  IN  MX  10  C . EXAMPLE . ORG 

B .  EXAMPLE .ORG  IN  WKS  10.0.0.2  TCP  SMTP 

C .  EXAMPLE . ORG  IN  MX  0  C . EXAMPLE . ORG 

C .  EX.AMPLE  .ORG  IN  WKS  10.0.0.3  TCP  SMTP 

D.  EXAMPLE. ORG  IN  MX  0  D . EXAMPLE . ORG 

D. EXAMP LE.ORG  IN  MX  0  C . EXAMPLE . ORG 

D . EXAMPLE .ORG  IN  WKS  10.0.0.4  TCP  SMTP 

In  the  first  example,  an  SMTP  mailer  on  D . EXAMPLE . ORG  is  trying  to 
deliver  a  message  addressed  to  A. EXAMPLE . ORG .  From  the  answer  to  its 
query,  it  learns  that  A . EXAMPLE . ORG  has  three  MX  RRs .  D . EXAMP LE . ORG 
is  net  one  of  the  MX  RRs  and  all  three  MXs  support  SMTP  mail 
(determined  from  the  WKS  entries),  so  none  of  the  MXs  are  eliminated. 
The  .m.ailer  is  obliged  to  try  to  deliver  to  A .  EXAMPLE . ORG  as  the 
lowest  valued  MX.  If  it  cannot  reach  A. EXAMPLE . ORG  it  can  (but  is 
r. :  t  required  to)  fy  B  .  EXAMPLE  .  ORG  .  and  if  B  .  EXAMPLE  .  ORG  is  not 
reup  :r.-iir:g,  it  can  try  C  .  EXAMPLE  .  ORG  . 

the  second  example,  the  mailer  is  on  B . EXAMPLE . ORG,  and  is  again 
'ryi.tg  to  deliver  a  message  addressed  to  A .  EXAMPLE  .  ORG  .  There  are 
■■r.::e  again  three  MX  RRs  for  A .  EXAMPLE .  ORG,  but  in  this  case  the 
.'taller  must  discard  the  RRs  for  itself  and  C .  EXAMPLE .  ORG  (because  the 
MX  PR  for  C . EXAMPLE . ORG  has  a  higher  preference  value  than  the  RR  for 

B .  EXAMPLE . ORG) .  It  is  left  only  with  the  RR  for  A . EXAMPLE . ORG,  and 
can  only  try  delivery  to  A . EXAMPLE . ORG . 

In  the  tnird  example,  consider  a  mailer  on  A . EXAMPLE . ORG  trying  to 
deliver  a  message  to  D . EXAMPLE . ORG .  In  this  case  there  are  only  two 
MX  RRs,  both  with  the  sam.e  preference  value.  Either  MX  will  accept 
messages  for  D . EXAMPLE . ORG .  The  mailer  should  try  one  MX  first  (which 
one  is  up  to  the  mailer,  though  D . EXAMPLE . ORG  seems  most  reasonable), 
and  if  that  delivery  fails  should  try  the  other  MX  (e.g. 

C .  EXAMPLE.ORG) . 


Partridge  [Page  7] 


4-193 


INTERNET  PROTOCOL  HANDBOOK  -  Volume  Four 


1989 


4-194 


Sources  of  Information  on  tlie  DNS 


1.9,  Sources  of  Information  on  the  DNS 

For  nunc  inlv'nnation  alx'ui  ihc  [)N.S,  incii  Jing  [urormaticm  rcnarJiny  cxisling  laiiilcinenlaiions  ol'  iJic  DNS,  the 
reader  can  pariu  ipaie  in  eniline  di^^  iisMon  groups,  parucipaie  in  liiieniel  working  groups,  and  euniael  die  the  DDN 
Neiwork  Inlonnaliini  Cenier  iDDN  MCi  at  SRI  International  in  Menlo  Park,  Calilornia,  in  a  nuniber  of  ways.  In  the 
IviUovs  ing,  we  pro\  ide  more  details  on  each  of  these  three  ixissibilaies. 


1.9.1.  Online  Discussion  (iroupt 

1.9.1. 1.  N.\MI:1)R()PP1:R.S  mailing  list 


'T'he  N.'kMF.DROPPFRS  online  mailing  list  wa.s  established  in  IPS.’'  to  fo.ster  teehmeal  discussion  about  the 
concepts,  design,  and  implementation  of  the  domain  naming  system.  Originally  conceived  as  a  convenient  means 
for  the  DNS  de\  elopers  to  review  the  nianv  draft  documents  desenbing  the  system,  the  list  is  now  the  main  avenue 
ot  eorrespoiivlence  among  both  ilevelopers  and  implemeiuors  who  are  actively  involved  in  the  ongoing  development 
of  the  DNS. 

Members  ol  the  list  are  e.vpected  to  participate  in  discu.ssi.ms  from  time  to  time;  it  is  not  meant  fi.ir  observers. 

.-Ml  prc'.  lotis  N.-WiriDROPFERS  diseusstons  can  be  found  in  files  on  host  N1C.DDN.MIL  tformerly  named  SRI 
N1C.,-\RP.\,)  at  Internet  host  address  26.0.0.7.'^  or  10. 0.0. M.  Filenames  follow  tlie  fomuit: 

N.A.MEDROPPERStN.AMFDROPPERS.vymmdd 

NAMEDKOPPF.RS:N.-\MEDROPPERS.yy 

.■\rehr.es  e.xist  for  the  >ears  19S.s  through  PISS.  For  most  years,  the  wliole  archive  m.is  fit  in  a  single  file;  those 
.ireliivcs  will  have  only  the  ">y  '  extension.  The  file  N,A.MI;DR(..)PPERS:.N,\.ME].)RfjPPERS,.M.AII.  contains  die 
most  current  N.AMEDRf.IPPER'^  ii.ilog.  .All  Ides  can  bo  accessed  m.i  anonymous  FTP;  new  memlx'rs  may  wish  to 
co[ty  and  read  the.sc  archi\  es  before  joining  the  discussion. 

To  participate  m  discussions,  users  should  send  e-mad  to  N.AMFDKt  IPlT.R.SOy  NIC. DDN, .MIL.  To  be  adkled  to  the 
mailing  list,  users  should  .send  e-mail  to  NA.MEDROPPERS-RlTdCF.S  I'm  NIC.DDN.MIL.  Rec{uesis  to  be  deleted 
from  the  mailing  list,  or  problem  report,  should  be  sent  to  N,-\MFDROPPF,RS-REQCEST(a'NlC.DDN.MIL.  List 
mainicnanec  is  performed  by  .NIC  systems  personnel  at  SRI  International;  die  list  is  coordinated  by  the  DDN  NIC 
liosima.ster.  HO.STMASTER(a  NIC.DDN.MIL. 

1.9. 1.2.  lll.ND  mailing  li.st 

The  Berkeley  Internet  Name-Domain  (BIND)  re.solvcr  and  server  for  UNIX  4BSD  is  one  of  the  most  prominent 
imiilenicnUition.s  of  the  DNS.  TTie  Cmvcrsily  of  California  maintains  die  BIND  mailing  li.st  for  questions,  an.swcrs, 
and  comments  about  the  BIND  nameserver.  It  includes  BIND  mainiaincrs  and  site  administrators  using  BIND. 
Discussions  include  current  bugs  and  fi.xcs,  questions  and  tinswcrs  about  domain  configuration  and  server,  and 
announcements  of  new  software  releases.  Archives  for  the  mailing  li.st  can  be  obtained  via  anonymous  KfP  from 
host  ucbarjia, Berkeley. FDU  from  the  directory  pub/liind.mail. 
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To  bo  added  to  the  mailing  list,  users  should  send  an  online  e-mail  message  to  bind- 

reiiueuto'uebarjra. Berkeley.EDU,  To  participate  in  discussions  on  the  mailing  list,  u.sers  should  send  e-mail 
messages  to  hind®  ucbarjja.Berkeles  .EDU. 

1.9.2.  Internet  Working  (Jroiips 

The  Internet  Engineering  Task  Force  (IETF)  has  an  ad-hoc  working  group  to  addrcs.s  domain  ^'•'sues.  The  group 
meets  at  regahnly  scheduled  IETF  meetings  as  needed  to  di.scuss  current  DNS  p.''t)blems  and  solutions.  To  learn 
more  alxiut  tlve  v,ork  of  diis  group,  users  should  contact  die  IETF  chaiqx’r.son,  currently  Phill  Gross, 
g r> ) ^ N(d  .S CCG .-s TE .  SCC. CO ,\  1 . 

1.9.3.  The  DD.N  NIC 

1. 9. 3.1.  DON  NIC  donittin  name  services 

rtie  DDN  NIC  currently  seiA  cs  as  die  registration  authordy  for  all  top-level  domains  in  the  DDN  Domain  Naming 
S\  ^lem  . D.NS;  under  contract  to  the  Defense  Communications  Agency  (DCA).  The  DDN  NIC  is  responsible  for 
administrative  and  technical  matters  concerning  ihe  top-level  domains  GOV',  ORG,  NET,  EDU,  COM,  MIL,  and 
.AKI'A,  and  registers  second-level  domains  and  their  domain  servers  under  these  domains.  In  addidon  to  providing 
daij  liles  for  use  by  the  root  .servers,  die  DDN  NIC  also  maintains  and  provides  a  machine-readable  host  name-to- 
■  :  Ircss  traii'laiion  table  for  emergency  backup  p'  .poses,  and  lists  of  administrative  and  technical  {xiinLs  of  contact 
;  ..  .:il  regisiered  domains. 

1.9. 3. 2.  Domain  registration 

( a  ....ii.i.'.iiiofi'  iliat  wish  to  regmler  a  domain  with  the  DD.N  NIC  should  complete  the  domain  application  form, 
v.fm  h  c.m  b'C  obtained  from  Internet  host  NIC. DDN. MIL  at  Internet  addresses  26.0.0.73  and  10. ().(). 51.  The 
p.iihname  lor  retrieving  the  file  via  online  file  transfer  is  NETINFOiDO.M.MN-TEMPL.-XTE.T.XT,  A  copy  of  the 
application  may  al.so  be  obLuned  by  .sending  an  e-mail  request  to  H0STM,A.STER@NIC.DDN.M1L  or  to  the 
mailbo.x  SERVlCE(q.NIC.DDN..MlL. 

1.9. 3. 3.  Online  informational  files 

•Several  informational  Hies  that  domain  implementors  will  find  useful  are  available  online  from  host  NTC.DDN.MIL. 

Top-Level  Domains:  The  file  NETi.NFOiDOMAINS.T.XT  contains  a  machine-readable  table  in  RFC  952  format  of 
top-level  domains  and  the  network  addresses  of  their  domain  name  servers.  The  file  NETINFO'.DOM  AIN- 
INF(i).TXT  lists  all  registered  top-level  domains  and  their  sccond  levei  subdomains  in  alphalxitical  order. 

Domain  Points  of  Contact:  Online  file  NETINFO: DOMAI.N-CONTACTS.TXT  lists  the  points  of  contact  for  each 
domain  registered  with  die  DD.N  NIC,  and  die  file  NETINT-OiDO.M.-MN-TEMPL.-VTE.TXT  contains  die  registration 
lorm  to  be  used  in  rcgislcriiig  a  lop-lcvcl  or  .sccond-lcvcl  domain  with  the  DD.N  NIC. 

Root  Servers:  The  file  NETINFO:R()OT-SEK  VFRS.T.XT  lists  the  hostnames  and  network  addresses  of  the 
machines  diat  provide  root-level  domain  name  service  for  the  DNS. 

Registered  IP  Networks:  The  file  NE'riNFO:NET'\VORKS.TXT  provides  a  list  of  all  registered  IP  networks  mat  arc 
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pcrniuk'd  to  pass  traffic  on  llic  DDN/DARPA  Imcrnei. 

DNS  Intplcmcntations;  Ttic  file  NAMF.DROPPliRSiDNS-SOFT'WARF-’.TXT  contains  tlic  domain  software  catalog, 
siaru'd  by  Paul  Mockapetns.  For  each  D\S  impicinentafion,  this  catalog  li.->Ls  the  name  of  the  sysieim  version, 
ap[ilicab!e  OS,CPL',  availability,  name  server  and  re.solver  types,  whether  /one  transfers  are  supported,  the  transport 
jiroioci)!  used,  other  ..ofiuare  ret|iiired  for  use,  limitations,  source  of  infonnalion,  e-mail  and  postal-mail  address  of 
contact,  and  phone  number  of  contact.  Some  enuies  of  the  catalog  include,  in  addition,  the  programming  language 
usv  d,  filenames  to  FTP  (docunienuuion,  ccxle,  or  others),  and  special  features. 


1. 9.3.4.  Online  WHOIS  service 

The  DDN  NIC  provides  an  electronic  white-pages  service  for  Internet  users.  This  .service,  calftid  WHOIS  (or 
NIC.\.A.ME  at  some  sites),  delivers  d  'ta  to  network  users  by  means  of  a  last  qucry/rc.;pon.sc  transaction  over  the 
network.  Domain,  host,  T.AC,  and  network  information  may  be  obtained  from  WHOIS  in  addition  to  information 
about  inJis  idiia!  re^. stored  users  and  points  of  contact  for  various  regi.Nicred  entities. 

Remole  users  can  use  a  WHOIS  program  on  their  local  hosts,  if  available,  or  telnet  to  NIC.DDN.MIL  and  invoke  the 
A'llOIS  pr^'gra;n  tlicro.  For  help  using  the  program,  users  type  "whoiv  help"  (or  "nicnamc  help")  at  the  "(&"  system 
prompt,  V.  HOIS  user  programs  for  several  operating  systems  are  available;  users  should  contact  the  DDN  NIC  for 
copies. 

To  obtain  information  about  a  sttecific  domain,  a  u.ser  invokes  WHOIS  from  a  local  host  or  telnets  to  host 
N1C.DDN.MIL..  then  issuer  the  command  at  "(a"  prompt: 
whole  dca.aln  <doma  ir;-name>  <Hetarn> 


In  response,  tfie  WHOIS  server  w  ill  display  the  name  of  the  organization  that  registered  the  domain,  NIC  "handle” 
la  unique  i.Liiaha.se  identifier)  of  the  domain,  and  the  addres.s  of  organization;  the  name  of  domain;  the  administrative 
and  technical  contacts  lor  the  domain;  a  list  of  regis.ercd  domain  name  .servers  for  domain;  and  any  registered 
subdomains  or  hosts. 


f  or  c.xampic: 

who  1,5  domain  gov  <Return> 
d  .  ;ij  .  Gover.'.rr.ent  Dorr'ain  (GOV-DCM) 

osm.ain  ttam.e  :  GCV 

F-.  1.':.  1  r.  i  .5 1  r  a  t  i  ve  Corit  a o  t  ; 

Chle,  William  A.  (W’AO't)  ohle@OSI.ICST.tjBS.GOV 
(1C2)  166-0220 

Teoioiioal  Contact,  Zone  Contact: 

sot.-T.aster  OiCSTMASTER)  HOSTMASTER@tJ IC  .  DDN  .  MI L 

(800)  235-31^5  (415)  859-3695 

Z  r'.'iir.  servero  in  listed  order: 


A  .  IS  I  .  ZD'J 
TER?  .  CMD  .  EE’J 

gc:;tep-8::am.  AE  .mil 

1  *  ..1 . ;  •  f'. . .  .  6,0 '/ 


26.0.0.73,  10.0.0.51 

26.3.0.103 

192.33.4.12 

10. 1.0. 17,  128.8.10.90 
26.1.0.13 
128  . 102 .16.10 
128.29.1.2,  192.5.25.82 
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Y-'u  like  to  see  the  known  domains  under  this  top-level  domain?  y 


-here  are  30  known  sub-domains: 


Argonne  National  Laboratory 

National  Institute  of  Staniards  and  Techno 
Brookhaven  National  Laboratory 
Continuous  Electronic  Beam  Accelerator  Fac 
Center  for  Seismic  Studies 
matches.  Show  themd  no 


Further  Information 


I-'or  iLirihor  ml'ormaUoii,  coiuatl  the  DDN  NIC  directly  by  L'.S.  postil  mail: 
SRI  IntcrnatiC'iial 

DD.N  Nclsvork  litloniiaiion  Ccnicr 
33,'  Rawnswixid  Anoiilic,  Room  bJ2'M 
Menlo  F'ark,  C.A  S)4i)25 

o-maii: 

■MC'C  NIC'  DDN. .MIL  Tor  general  iniirrmalion 
HCiSl'MASTLRCi  NIC. DDN. MIL.  I'ur  donuiin-spccil'ic  inl'ormation 

telephone: 

I  S0< I)  23.S-3 1 .3.3 

i-llSi  S.39-36y5 
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2.  THE  INTERNET  HOST  TABLE 

Section  2  coriuiins  RFCs  tfiat  describe  the  Internet  Most  Table,  which  was  used  to  map  host  names  to  Internet 
addresses  in  tlte  past,  before  the  DN'S  was  developed. 

RFC  9.S2  specifies  the  format  for  the  ofl'icial  Internet  Host  Table  and  is  used  by  the  DoD  Hostname  Server.  The 
Internet  Host  Table  is  a  machine-readable  file  that  contains  data  alxtut  networks,  gateways,  and  hosts  connected  to 
the  DDN  Internet.  Tliis  RFC  shows  examples  of  tlie  format  of  tlie  encis’s  and  syntax  used  in  the  Internet  Host  Table, 
and  explains  die  methods  used  to  obtain  copies  of  the  Lible  via  FTP  or  by  using  tlie  Hostname  Server  Protocol 
described  in  RFC  953.  This  RFC  obsoletes  RFC  810. 

RFC  R.*!.!  describes  the  Hostname  Server  Protocol  that  delivers,  by  way  of  a  TCP  connection,  machine-readable 
name  and  adtlress  data  on  networks,  gateways,  hosts,  and  domains  in  die  Internet  that  are  registered  with  the  DDN 
NIC.  This  RFC  de.scribes  the  quer>7rc.spon.se  format  and  command/response  keywords  that  arc  recognized  by  the 
server,  and  gives  examples  of  common  types  of  possible  transactions,  including  how  to  get  the  full  Internet  Host 
Table.  This  RFC  obsoletes  RFC  811, 
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2.1.  DOD  Internet  Host  Table  Specification  [RFC  952] 


Network  Working  Group  K.  Harrenstien(SRI) 

Request  for  Comments:  952  M.  Stahl  (SRI) 

E.  Feinler  (SRI) 

Obsoletes:  RFC  810,  608  October  1985 
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STATUS  OF  THIS  MEMO 

This  RFC  is  the  official  specification  of  the  format  of  the  Internet 
Host  Table.  This  edition  of  the  specif ication  includes  minor 
revisions  to  RFC-810  which  brings  it  up  to  date.  Distribution  of  this 
memo  is  unlimited. 

INTRODUCTION 

The  DoD  Host  Table  is  utilized  by  the  DoD  Hostname  Server  maintained 
by  the  DDN  Network  Information  Center  (NIC)  on  behalf  of  the  Defense 
Communications  Agency  (DCA)  [See  RFC-953] . 

LOCATION  OF  THE  STANDARD  DOD  ONLINE  HOST  TABLE 

A  machine-translatable  ASCII  text  version  of  the  DoD  Host  Table  is 
online  in  the  file  NETINFO : HOSTS . TXT  on  the  SRI-NIC  host.  It  can  be 
obtained  via  FTP  from  your  local  host  by  connecting  to  host 
SRI-NIC. ARPA  (26.0.0.73  or  10.0.0.51),  logging  in  as  user  = 

ANONYMOUS,  password  =  GUEST,  and  retrieving  the  file 

"NETINFO : HOSTS . TXT" .  The  same  table  may  also  be  obtained  via  the  NIC 
Hostnam.e  Server,  as  described  in  RFC-953.  The  latter  method  is 
faster  and  easier,  but  requires  a  user  program  to  make  the  necessary 
connection  to  the  Nam.e  Server. 

ASSUMPTION'S 

1.  A  "name"  (Net,  Host,  Gateway,  or  Domain  name)  is  a  text  string  up 
to  24  characters  drawn  from  the  alphabet  (A-Z) ,  digits  (0-9),  minus 
sign  (-) ,  and  period  (.) .  Note  that  periods  are  only  allowed  when 
they  serve  to  delimit  components  of  "domain  style  names".  (See 
RFC-921,  "Domain  Name  System  Implementation  Schedule",  for 
background) .  No  blank  or  space  characters  are  permitted  as  part  of  a 
name.  No  distinction  is  m.ade  between  upper  and  lower  case.  The  first 
character  must  be  an  alpha  character.  The  last  character  must  not  be 
a  minus  sign  or  period.  A  host  which  serves  as  a  GATEWAY  should  have 
"-GATbWAY"  or  "-GW"  as  part  of  its  name.  Hosts  which  do  not  serve  as 
Internet  gateways  should  not  use  "-GATEWAY"  and  "-GW"  as  part  of 
their  names.  A  host  which  is  a  TAC  should  have  "-TAC"  as  the  last 
part  of  its  host  name,  if  it  is  a  DoD  host.  Single  character  names 
or  nicknames  are  not  allowed. 

2.  Internet  Addresses  are  32-bit  addresses  [See  RFC-796] .  In  rhe 
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host  table  described  herein  each  address  is  represented  by  four 
decimal  numbers  separated  by  a  period.  Each  uecimal  nuirber 
represents  1  octet  . 

3.  If  the  first  bit  of  the  first  octet  of  the  address  is  0  (zero), 
then  the  next  7  bits  of  the  first  octet  indicate  the  network  number 
(Class  A  Address).  If  the  first  two  bits  are  1,0  (one, zero),  then 
the  next  14  bits  define  the  net  number  (Class  B  Address) .  If  the 
first  3  bits  are  1,1,0  (one, one, zero) ,  then  the  next  21  bits  define 
the  net  number  (Class  C  Address)  [See  RFC-943] . 

This  is  depicted  in  the  following  diagram: 

+  -  + - + - + - + - + 

10  I  NET  <-7->  I  LOCAL  ADDRESS  <-24->  I 

+  _  + - + - + - + - + 

+ - + - + - + - + - + 

1101  NET  <-14->  1  LOCAL  ADDRESS  <-16->  I 

+ - + - + - + - + - + 

+ - + - + - + - + - + 

11101  NET  <-21->  I  LOCAL  ADDRESS  I 

- — - ^ - — —  —  —  —  —  ^ — -  -  - - —  —  —  _  —  __4. 

4.  The  LOCAL  ADDRESS  portion  of  the  internet  address  identifies  a 
host  within  the  network  specified  by  the  NET  portion  of  the  address. 

5.  The  ARPANET  and  MILNET  are  both  Class  A  networks.  The  NET  portion 
is  10  decimal  for  ARPANET,  26  decimal  for  MILNET,  and  the  LOCAL 
ADDRESS  maps  as  follows:  the  second  octet  identifies  the  physical 
host,  the  third  octet  identifies  the  logical  host,  and  the  fourth 
identifies  the  Packet  Switching  Node  (PSN) ,  formerly  known  as  an 
Interface  Message  Processor  (IMP) . 

+  -  + - + - + - + - + 

10  I  10  or  26  I  HOST  I  LOGICAL  HOST  |  PSN  (IMF)  | 

+  _  + - + - + - + - + 

(NOTE:  RFC-796  also  describes  the  local  address  mappings  for 

several  wther  networks.) 

6.  It  is  the  responsibility  of  the  users  of  this  host  table  to 
translate  it  into  whatever  format  is  needed  for  their  purposes. 

7.  Names  and  addresses  for  DoD  hosts  and  gateways  will  be  negotiated 
and  registered  with  the  DDN  PMO,  and  subsequently  with  the  NIC, 
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before  being  used  and  before  traffic  is  passed  by  a  DoD  host.  Names 
and  addresses  for  domains  and  networks  are  to  be  registered  with  the 
DDN  Network  Information  Center  (HOSTMASTERGSRI -NIC . ARPA)  or 
800-235-3155  . 

The  NIC  will  atte.mpt  to  keep  similar  information  for  non-DoD  networks 
and  hosts,  if  this  information  is  provided,  and  as  long  as  it  is 
needed,  i.e.,  until  intercommunicating  network  name  servers  are  in 
place . 

EXAMPLE  OF  HOST  TABLE  FORMAT 


NET  •  10.0.0.0  ;  ARPANET  ; 

NET  ;  128.10.0.0  :  PURDUE-CS-NET  : 

GATEWAY  :  10.0.0.77,  18.10.0.4  :  MIT-GW . ARPA, MIT-GATEWAY  :  PDP-11  : 

MOS  :  IP/GW, EGP  ; 

HOST  :  26.0.0.73,  10.0.0.51  :  SRI-NIC . ARPA, SRI-NIC, NIC  ;  DEC-2060  ; 

TOPS20  :TCP/TELNET, TCP/SMTP, TCP/TIME, TCP/FTP, TCP/ECHO, ICMP  : 
HOST  ;  10.2.0.11  :  SU-TAC . ARPA, SU-TAC  :  C/30  ;  TAC  :  TCP  ; 

SYNTAX  AND  CONVENTIONS 


;  (semicolon) 

NET 

GATEWAY 
HOST 
DOMAIN 
:  (colon) 

:  ;  (2  colons) 

,  (corrma) 


is  used  to  denote  the  beginning  of  a  comment . 
Any  text  on  a  given  line  following  a  ' ; '  is  a 
comment,  and  not  part  of  the  host  table. 

keyword  introducing  a  network  entry 

keyword  introducing  a  gateway  entry 

keyword  introducing  a  host  entry 

keyword  introducing  a  domain  entry 

is  used  as  a  field  delimiter 

indicates  a  null  field 

is  used  as  a  data  element  delimiter 


XXX/YYY 


indicates  protocol  information  of  the  type 
TRANSPORT/SERVICE . 


where  TRANSPORT/SERVICE  options  are  specified  as 

"FOO/BAR"  both  transport  and  service  known 
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"FOO"  transport  known;  services  not  known 

"BAR"  service  is  known,  transport  not  known 

NOTE;  See  "Assigned  Numbers"  for  specific  options  and  acronyms 
for  mach-'ne  types,  operating  systems,  and  protcccl/sarvices  . 

Each  host  tabbe  entry  is  an  ASCII  text  string  comprised  of  6  fields, 
where 


F ie Id  1 


Field  2 


P  0  1  H  3 

Field  4 
Field  5 
Field  6 


KEYWORD  indicating  whether  this  entry  pertains  to 
a  NET,  GATEWAY,  HOST,  or  DOMAIN.  NET  entries  are 
assigned  and  cannot  have  alternate  addresses  or 
nicknames.  DOMAIN  entries  do  not  use  fields  4,  5, 

or  6  . 

Internet  Address  of  Network,  Gateway,  or  Host 
followed  by  alternate  addresses.  Addresses  for  a 
Domain  are  those  where  a  Domain  Name  Server  exists 
for  that  domain. 

Official  Name  of  Network,  Gateway,  Host,  or  Domain 
(with  optional  nicknames,  where  permitted) . 

Machine  Type 

Operating  System 

Protocol  List 


Fields  4,  5  and  6  are  optional.  For  a  Domain  they  are  not  used. 

Fields  3-6,  if  included,  pertain  to  the  first  address  in  Field  2. 

'Blanks'  (spaces  and  tabs)  are  ignored  between  data  elements  or 
fields,  but  are  disallowed  within  a  data  element. 

Each  entry  ends  with  a  colon. 

The  entries  in  the  table  are  grouped  by  types  in  the  order  Domain, 
Net,  Gateway,  and  Host.  Within  each  type  the  ordering  is 
unspec i f ied . 

Note  that  although  optional  nicknames  are  allowed  for  hosts,  they  are 
discouraged,  except  in  the  case  where  host  names  have  been  changed 
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and  both  the  new  and  the  old  names  are  maintained  for  a  suitable 
period  of  time  to  effect  a  smooth  transition.  Nicknames  are  not 
permitted  for  NET  names. 

GRAMMATICAL  HOST  TABLE  SPECIFICATION 

A.  Parsing  grammar 

<entry>  <keyword>  <addresses>  <names>  [ " ; "  [<cputype>] 

[<opsys>]  [<protocol  list>]  ]]] 

<addresses>  ::=  <address>  <address>] 

<address>  :;=  <oct€t>  <octet>  <octet>  <octet> 

<octet>  : :=  <0  to  255  decimal> 

<names>  :;=  <netname>  I  <gatename>  I  <domainname> 

<nicknames>] 

i  <official  hostname>  <nicknames>] 

<netname>  ;:=  <name> 

<gatename>  :;=  <hname> 

<domainname>  ::=  <hname> 

<official  hostname>  ::=  <hname> 

<nickname>  ::=  <hname> 

kprotocol  list>  <protocol  speO  -^protocol  spec>] 

kprotocol  spec>  : :=  <transport  name>  "/"  <service  name> 

I  <raw  protocol  name> 

B.  Lexical  grammar 

<entry-f ield>  : :=  <entry-text>  [<cr><lf>  <blank>  <entry-f ield>] 
<entry-text>  ::=  <print-char>  *<text> 

<blank>  ;:=  <space-or-tab>  [<blank>] 

<keyword>  ::=  NET  |  GATEWAY  I  HOST  I  DOMAIN 
<hname>  <name>* [ " . "<name>] 

<name>  ::=  <let> [ * [<let-or-digit-or-hyphen>] <let-or-digit>] 
<cputype>  ; :=  PDP-11/70  I  DEC-1080  I  C/30  I  CDC-6400 . . .etc . 

<opsys>  ;:=  ITS  |  MULTICS  I  TOPS20  I  UNIX... etc. 

<transport  name>  ::=  TCP  |  NCP  I  UDP  I  IP... etc. 

<service  names  ::=  TELNET  |  FTP  |  SMTP  |  MTP...etc. 

<raw  protocol  names  :;=  <nameS 
kcomments  ;:=  <texts<crs<lf s 

<texts  ;:=  * [<print-charS  |  <blanks] 

<print-chars  ::=  <any  printing  char  (not  space  or  tab) S 
Notes  ; 

1.  Zero  or  more  'blanks'  between  separators  ",  :  "  are  allowed. 

'Blanks'  are  spaces  and  tabs. 
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2.  Continuation  lines  are  lines  that  begin  with  at  least  one 
blank.  They  may  be  used  anywhere  'blanks'  are  legal  to  split  an 
entry  across  lines. 
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STATCS  OF  THIS  MEMO 

This  RFC  is  the  official  specification  of  the  Hostname  Server 
Protocol.  This  edition  of  the  specification  includes  minor  revisions 
to  RFC  811  which  brings  it  up  to  date.  Distribution  of  this  memo  is 
uni imited . 

INTRODUCTION 

The  NIC  Internet  Hostname  Server  is  a  TCP-based  host  information 
program  and  protocol  running  on  the  SRI-NIC  machine.  It  is  one  of  a 
series  of  internet  name  services  maintained  by  the  DDN  Network 
Information  Center  (NIC)  at  SRI  International  on  behalf  of  the 
Defense  Communications  Agency  (DCA) .  The  function  of  this  particular 
server  is  to  deliver  machine-readable  name/address  information 
describing  networks,  gateways,  hosts,  and  eventually  domains,  within 
the  internet  environment.  As  currently  implemented,  the  server 
provides  the  information  outlined  in  the  DoD  Internet  Host  Table 
Specification  [See  RFC-952].  For  a  discussion  of  future  developments 
see  also  RFC-921  concerning  the  Domain  Name  System. 

PROTOCOL 

To  access  this  server  from  a  program,  establish  a  TCP  connection  to 
port  101  (decimal)  at  the  service  host,  SRI-NIC. ARPA  (26.0.0.73  or 
10.0.0.51).  Send  the  information  request  (a  single  line),  and  read 
the  resulting  response.  The  connection  is  closed  by  the  server  upon 
completion  of  the  response,  so  only  one  request  can  be  made  for  each 
connection . 

QUERY/RESPONSE  FORMAT 

The  name  server  accepts  simple  text  query  requests  of  the  form 

<command  key>  kargument (s) >  [<options>] 

where  square  brackets  ("[]")  indicate  an  optional  field.  The  command 
key  is  a  keyword  indicating  the  nature  of  the  request.  The  defined 
keys  are  explained  below. 

The  response,  on  the  other  hand,  is  of  the  form 
kresponse  key>  :  krest  of  response> 
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where  <response  key>  is  a  keyword  indicating  the  nature  of  the 
response,  and  the  rest  of  the  response  is  interpreted  in  the  context 
of  the  kev. 


Care  s  h  c  u ] 


^axen  to 


interpret  the  nature  of  the  reply 


(e.g,  single  reocrd  or  multiple  record),  so  that  no  confusion  about 
the  state  of  the  reioly  results.  An  "ALL"  request  will  likely  return 
several  hundred  or  more  records  of  all  types,  whereas  "HNAME"  or 
".".r.LCR"  will  usuallv  return  one  HOST  record. 


The  currently  defined  comnand  keywords  are  listed  below.  NOTE: 
Because  the  server  and  the  features  available  will  evolve  with  time, 
the  HELP  command  should  be  used  to  obtain  the  most  recent  summary  of 
irrpierriented  features,  changes,  or  new  co.monands . 

Keyword  Response 

HELP  This  information. 

VERSION  "VERSION:  <string>"  where  <string>  will  be  different  for 
each  version  of  the  host  table. 


iN'.^llE  <hostnarrie> 

One  or  more  matching  host  table  entries. 


•i.kCOR  <hostaddr> 

One  or  more  rr.atc'r.ing  host  table  entries. 

ALL  The  entire  host  table. 

ALL-OLD  The  entire  host  table  without  domain  style  names. 


DOMAINS 


ihe  entire  top-level  domain  table  (domains  only) 


ALL-DOM  Both  the  entire  domain  table  and  the  host  table. 


ALL-INGWAY 


All  known  gateways  in  TENEX/TOPS-20  INTERNET . GATEWAYS 
format . 


Remember  that  the  server  accepts  only  a  single  command  line  and 
returns  only  a  single  response  before  closing  the  connection.  HNAME 
and  HADDP  are  useful  for  looking  up  a  specific  host  by  name  or 
address;  VERSION  can  be  used  by  automated  processes  to  see  whether  a 
"new"  version  of  the  host  table  exists  without  having  to  transfer  the 
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whole  table.  Note,  however,  that  the  returned  version  string  is  only 
guaranteed  to  be  unique  to  each  version,  and  nothing  should  currently 
be  assumed  about  its  format. 


Response  Keys : 


ERR 


h^E  T 


GATEWAY 


ent  ry 

not  found. 

nature  of 

error  f ol lews 

entry 

f  ound. 

rest 

of 

ent  ry 

follows 

ent  ry 

found. 

rest 

of 

ent  ry 

follows 

ent  ry 

found. 

rest 

of 

ent  ry 

follows 

ent  ry 

found. 

rest 

of 

ent  ry 

f  C  1  1  ■  J  w  s 

folic 

wed  by 

.mu  1 1  i 

pie 

ent  r ies 

done  with  BEGIN  block  ot  entries 


.Yore  keywords  will  be  added  as  new  needs  are  recognized.  A  more 
detailed  de,scription  of  the  allowed  requests.' responses  follows. 


Cl'ERi /RESPONSE  EXAMPLES 

1.  .H.N'AME  Query  -  Given  a  name,  find  the  entry  or  entries  that  match 
the  name.  E'er  example; 

.RN.ANE  SRl-N'IC  .  ARPA  <CRLF> 

where  <CP.EF>  is  a  carriage  return/  linefeed,  and  '  SRI-NIC .  ARFA' 
is  a  host  name 


.  1  ^  V 


26.0.0.73,  .0.0.0.51  :  SRI-NIC . ARPA, SRI-NIC, NIC  : 

LEC-2060  :  7CP320  :  TCP/TELNET,  TCP/ 3.YTP,  TCP/TIME,  TCP/FTP, 
TCP/ECHO, ICMP  : 


A  response  may  stretch  across  more  than  o.ne  line.  Continuation 
lines  always  begin  with  at  least  one  space. 


2.  H.ADDR  Query  -  Given  an  internet  address  (as  specified  in  RFC  7  96) 
fiiid  the  entry  or  entries  that  match  that  address.  For  example: 


HADDR  26.0.0.73  <CRLF> 


where  <CRLF>  is  a  carriage  return/  linefeed,  and  '26.0.0.73'  is 
a  host  address. 

The  likely  response  is  the  same  as  for  the  previous  HNAME  request. 
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3.  ALL  Query  -  Deliver 
rr.achine-readable  form. 

ALL  <CRLF>  /where 

Th.e  likely  response 
' follcwed  by  the 
specified  in  RFC-952 


the  entire  internet 
For  example: 

<CRLF>  is  a  carriage 

is  the  keyword  'BEGIN 
entire  internet  ho.st 
,  foIlc-wed  by  'END;'  . 


host  table  in  a 

return/ linefeed 

followed  by  a  colon 
table  in  the  format 


FRRCR  K.AKDLING 


p  e  r  .T  i  1 1  e  d  i  .n  a  r.  y 
of  t .he  form 


err  r  and,  in  o.me  caces,  t  bar.  it  automatically, 
s  an  accorrpanyrng  message  for  a  given  error  for  that  case 
L;rcgrarr  singly  logs  the  err  r  message.  Current 
eir  associated  interpretations  are 

Name  no-t  fr.und;  name  not  in  table 
Aiiress  not  fO'und;  address  riot  :  tdiu.e 
I -legal  corrmand;  command  key  r. "-t  recognized 
Cvmp'tary  system  failure,  try  again  later 
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DOMAIN  NAME  ACRONYMS 


A 

Internet  Address 

AA 

Authoritative  Answer 

ARPA 

Advanced  Research  Projects  Agency 

ASN 

Aulomomous  System  Number 

AXFR 

Special  zone  transfer  QTYPE 

BIND 

Berkeley  Internet  Name  Domain  server 

CH 

The  Chaos  system 

CNAME 

Canonical  Name  (nickname  pointer) 

COM 

Commercial 

CPU 

Central  Processing  Unit 

cs 

eSNET  class  (obsoletc-seen  in  obsolete  RFCs) 

CSNET 

Computer  Science  Network 

DA 

Domain  Administrator 

DARPA 

Defense  Advanced  Research  Projects  Agency 

DDN  NIC 

Defense  Data  Network  -  Network  Information  Center 

DDN  PMO 

Defense  Data  Network  Program  Management  Office 

DNS 

Domain  Name  System 

EDU 

Education 

EGP 

Exterior  Gateway  Protocol 

FTP 

File  Transfer  Protocol 

GGP 

Gateway-to-Gateway  Protocol 

GOV 

Government 

HIN’FO 

Host  Information 

HS 

Hesiod  class 

IETF 

Internet  Engineering  Task  Force 

IMP 

Interface  Message  Processor  (see  PSN) 

IN 

Internet 

IP 

Internet  Protocol 

MAILA 

Mail  Agent  RRs  (obsolctc-sce  MX) 

MAILB 

Mailbox  (request  for  rccords-MB,  MG,  or  MR) 

MB 

Mailbox  Domain  name 

MD 

Mail  Destination  (obsolete-use  MX) 

MF 

Mail  Forwarder  (obsolete-use  MX) 

MG 

Mail  Group 

MIL 

Military 

MINFO 

Mailbox  or  mail  list  information 

MR 

Mail  Rename 

MX 

Mail  Exchanger 

ME 

Name  Error 

NIC 

Network  Information  Center 

NS 

Name  Server 

NULL 

Null  RR 

ORG 

Organization 

OS 

Operating  System 
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PSN 

PTR 

QCLASS 

QNAME 

QR 

QTYPE 

RA 

RCODE 

RD 

RDATA 

RDLEXGTH 

RFC 

RR 

:iBELT 

SCLASS 

SLIST 

SNAME 

SOA 

STYPE 

T(' 

■  Vi 

ITL 

TXT 

LDP 

WKS 

Z 


Packet  Switched  Node  (formerly  IMP) 

Pointer 
Query  Class 
Query  Domain  Name 
Query  or  Response 
Query  Type 
Recursion  Available 
Response  Code 
Recursion  Desired 
Resource  Data 
RDATA  Length 
Request  for  Comments 
Resource  Record 
Safety  Belt 

the  Class  of  the  Search  request 

Structure  describing  name  sersers  and  the  zone  which  the  resolver  is  trying  to  query 

Domain  name  search 

Start  Of  Authority 

the  QTYPE  of  the  search  request 

Truncation 

Transmission  Control  Protocol 

Time  To  Live 

Text 

User  Datagram  Protocol 
Well  Known  Services 
Zero  all  queries  and  responses 


